backend-coder
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.
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.
Almaty (Alma-Ata) 
Available for hire