Vladimir Ilmenev
Offer Vladimir work on your next project.
Private message
Offer work
Almaty (Alma-Ata),
Kazakhstan
8 months back
available for hire
on the service 8 months 13 days
Rating
Successful projects
Average rating
Rating
Portfolio
-
4647 USD full-stack development
Web Programming
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.
-
7000 USD backend-coder
Python
Creating the backend for Skyeng is not about "making a website." It's about building a digital city that operates 24/7. My task is to design and construct all its invisible infrastructure: the engine that allows thousands of people to meet, learn, and communicate in real-time simultaneously.
Architecture: Goodbye, monolith
It was immediately decided to abandon the monolith in favor of microservices. Such a complex project must be flexible and fault-tolerant. I divided all the logic into independent services:
…
Auth Service: Access control (JWT, roles).
Scheduler Service: The brain of the platform. Juggling thousands of lessons, taking into account the time zones of teachers from Brazil and students from Vladivostok.
Matching Service: Intelligent matching of the perfect "student-teacher" pair.
Billing Service: Management of subscriptions, payments, and salaries. Maximum reliability.
Classroom Service: The conductor of the lesson, operating in real-time.
The connection between them is through an asynchronous message bus (like RabbitMQ), so that the failure of one service does not affect the entire system.
The heart of the system: Virtual classroom
The interactive Vimbox classroom is the most complex and interesting part. It is a stateful application where latency is unacceptable.
Here, I bet on WebSockets. When a teacher draws on the virtual board, their browser does not bombard the server with requests. Instead, a persistent channel is established between them, the server, and the student. The teacher's client sends an event (for example, {"event": "draw", "coords": [x1, y1, x2, y2]}), my service in Go catches it and instantly forwards it to the student for rendering on their canvas. The entire process takes milliseconds, ensuring complete synchronization.
Routing video and audio streams through our servers is a pointless load. For this, WebRTC is used, allowing browsers to communicate directly (peer-to-peer). My backend merely "introduces" them, providing signaling for establishing the connection.
Technologies and infrastructure
The stack was selected for specific tasks for maximum performance:
Languages: Go for high-load real-time services (Classroom), Python (FastAPI) for the rest of the business logic.
Databases: PostgreSQL as the main relational database, Redis for caching everything and anything, as well as a broker for WebSockets.
Infrastructure: All services are packaged in Docker containers and managed by the Kubernetes orchestrator. This provides automatic scaling: if the load increases, Kubernetes automatically spins up new copies of the required service.
The main challenge: Time zones
This is the quiet horror of any global project. There is one solution, and it is not negotiable: on the backend, all dates and times are stored exclusively in UTC. Absolutely everything. The client application is responsible for converting to the user's local time. Any other approach is a guaranteed disaster in the future.
In the end, my job is not just to "code features." It is the engineering of a complex, fault-tolerant, and fast distributed system that will not crash during peak hours when thousands of people around the world press the "Start Lesson" button.