full-stack development
Step 1: Architecture. Speed is paramount.
There is no complex interaction logic between thousands of users, so creating a zoo of microservices would be overengineering. I would choose a well-structured monolith or an architecture with several large services ("macroservices"). For example:
Core API: The main core that delivers dictionary data.
Users API: A service for managing users, their personal dictionaries, and progress in exercises.
This approach simplifies development and deployment, and for a project where 95% of requests are anonymous search queries, it is more than justified.
Step 2: The heart of the system — search
A regular relational database (like MySQL/PostgreSQL) will die on dictionary search queries. Doing SELECT * FROM words WHERE word LIKE '...%' on a table with tens of millions of records is suicide.
Therefore, the core of the system is a combination of two tools:
PostgreSQL: As the main, reliable storage. Here lies the "raw" dictionary with all relationships, word forms, examples. This is our source of truth.
Elasticsearch: A specialized search engine. All data from PostgreSQL is indexed in Elasticsearch.
How it works:
When a user types a word in the search, the query goes not to the database, but to Elasticsearch. It finds the relevant articles in milliseconds, corrects typos, selects relevant results, and returns their IDs. Only then does our backend go to PostgreSQL (or, even better, to the cache) with these IDs for the full data of the dictionary entry and delivers it to the user. This ensures lightning-fast search speed.
Step 3: Data pipeline and caching
The dictionary database is a huge array of data. They need to be sourced, processed, and prepared for use. I would build a content pipeline:
I would write parser scripts that can "read" different dictionary formats (for example, DSL, StarDict).
These scripts process the data, bring it to a unified structure, and load it into our main PostgreSQL database.
After loading, the indexing process in Elasticsearch is triggered.
Caching here is king. 90% of users search for the same popular words. There’s no point in hitting the database every time.
Redis is used for aggressive caching. Did you request the word "hello"? We returned the result from Elasticsearch/PostgreSQL and immediately saved it in Redis for a few hours. The next user searching for "hello" will get the answer from super-fast RAM in fractions of a millisecond.
Audio files with pronunciations, images, and other static content, of course, are not served from the application server. They are uploaded to a CDN (Content Delivery Network) and distributed from the nearest server to the user worldwide.
Step 4: User features
Personal dictionaries and exercises are classic CRUD functionality. PostgreSQL handles this excellently.
Personal dictionary: A simple table user_saved_words with a many-to-many relationship between users and words.
Exercises: Backend logic that takes words from the user's personal dictionary, generates answer options (incorrect options can be taken from similarly spelled or meaning words), and sends them to the frontend as a JSON object for training.
Technology stack
Language: Python (Django/FastAPI) or PHP (Symfony/Laravel). Both are perfect for content projects and rapid API development.
Databases: PostgreSQL (source of truth), Elasticsearch (search), Redis (cache).
Infrastructure: Docker for containerization. The application is deployed on several virtual servers behind Nginx as a load balancer. Simple, reliable, and efficient for this type of project.
In the end, working on WooordHunt is not about complex business logic, but about engineering elegance. It’s about creating a high-performance system optimized for reading data. The goal is to squeeze the maximum speed out of the hardware and software so that the user experience is smooth and instantaneous.
There is no complex interaction logic between thousands of users, so creating a zoo of microservices would be overengineering. I would choose a well-structured monolith or an architecture with several large services ("macroservices"). For example:
Core API: The main core that delivers dictionary data.
Users API: A service for managing users, their personal dictionaries, and progress in exercises.
This approach simplifies development and deployment, and for a project where 95% of requests are anonymous search queries, it is more than justified.
Step 2: The heart of the system — search
A regular relational database (like MySQL/PostgreSQL) will die on dictionary search queries. Doing SELECT * FROM words WHERE word LIKE '...%' on a table with tens of millions of records is suicide.
Therefore, the core of the system is a combination of two tools:
PostgreSQL: As the main, reliable storage. Here lies the "raw" dictionary with all relationships, word forms, examples. This is our source of truth.
Elasticsearch: A specialized search engine. All data from PostgreSQL is indexed in Elasticsearch.
How it works:
When a user types a word in the search, the query goes not to the database, but to Elasticsearch. It finds the relevant articles in milliseconds, corrects typos, selects relevant results, and returns their IDs. Only then does our backend go to PostgreSQL (or, even better, to the cache) with these IDs for the full data of the dictionary entry and delivers it to the user. This ensures lightning-fast search speed.
Step 3: Data pipeline and caching
The dictionary database is a huge array of data. They need to be sourced, processed, and prepared for use. I would build a content pipeline:
I would write parser scripts that can "read" different dictionary formats (for example, DSL, StarDict).
These scripts process the data, bring it to a unified structure, and load it into our main PostgreSQL database.
After loading, the indexing process in Elasticsearch is triggered.
Caching here is king. 90% of users search for the same popular words. There’s no point in hitting the database every time.
Redis is used for aggressive caching. Did you request the word "hello"? We returned the result from Elasticsearch/PostgreSQL and immediately saved it in Redis for a few hours. The next user searching for "hello" will get the answer from super-fast RAM in fractions of a millisecond.
Audio files with pronunciations, images, and other static content, of course, are not served from the application server. They are uploaded to a CDN (Content Delivery Network) and distributed from the nearest server to the user worldwide.
Step 4: User features
Personal dictionaries and exercises are classic CRUD functionality. PostgreSQL handles this excellently.
Personal dictionary: A simple table user_saved_words with a many-to-many relationship between users and words.
Exercises: Backend logic that takes words from the user's personal dictionary, generates answer options (incorrect options can be taken from similarly spelled or meaning words), and sends them to the frontend as a JSON object for training.
Technology stack
Language: Python (Django/FastAPI) or PHP (Symfony/Laravel). Both are perfect for content projects and rapid API development.
Databases: PostgreSQL (source of truth), Elasticsearch (search), Redis (cache).
Infrastructure: Docker for containerization. The application is deployed on several virtual servers behind Nginx as a load balancer. Simple, reliable, and efficient for this type of project.
In the end, working on WooordHunt is not about complex business logic, but about engineering elegance. It’s about creating a high-performance system optimized for reading data. The goal is to squeeze the maximum speed out of the hardware and software so that the user experience is smooth and instantaneous.
Almaty (Alma-Ata) 
Available for hire