backend-coder
Создание бэкенда для Skyeng — это не про «сделать сайт». Это про строительство цифрового города, работающего 24/7. Моя задача — спроектировать и возвести всю его невидимую инфраструктуру: движок, который позволяет тысячам людей одновременно встречаться, учиться и общаться в реальном времени.
Архитектура: Прощай, монолит
Сразу было решено отказаться от монолита в пользу микросервисов. Такой сложный проект должен быть гибким и отказоустойчивым. Я разбил всю логику на независимые службы:
Auth Service: Контроль доступа (JWT, роли).
Scheduler Service: Мозг платформы. Жонглирует тысячами уроков, учитывая часовые пояса преподавателей из Бразилии и студентов из Владивостока.
Matching Service: Интеллектуальный подбор идеальной пары «ученик-учитель».
Billing Service: Управление подписками, платежами и зарплатами. Максимальная надежность.
Classroom Service: Дирижер урока, работающий в реальном времени.
Связь между ними — через асинхронную шину сообщений (вроде RabbitMQ), чтобы падение одного сервиса не повлияло на всю систему.
Сердце системы: Виртуальный класс
Интерактивный класс Vimbox — это самое сложное и интересное. Это stateful-приложение, где задержка недопустима.
Здесь я сделал ставку на WebSockets. Когда учитель рисует на виртуальной доске, его браузер не бомбит сервер запросами. Вместо этого между ним, сервером и учеником установлен постоянный канал. Клиент учителя отправляет событие (например, {"event": "draw", "coords": [x1, y1, x2, y2]}), мой сервис на Go ловит его и мгновенно пересылает ученику для отрисовки на его холсте. Весь процесс занимает миллисекунды, обеспечивая полную синхронизацию.
Видео и аудиопоток гонять через свои серверы — бессмысленная нагрузка. Для этого используется WebRTC, позволяющий браузерам общаться напрямую (peer-to-peer). Мой бэкенд лишь «знакомит» их, обеспечивая служебный сигналинг для установки соединения.
Технологии и инфраструктура
Стек подбирался под конкретные задачи для максимальной производительности:
Языки: Go для высоконагруженных сервисов реального времени (Classroom), Python (FastAPI) для остальной бизнес-логики.
Базы данных: PostgreSQL как основная реляционная база, Redis для кеширования всего и вся, а также как брокер для WebSockets.
Инфраструктура: Все сервисы упакованы в Docker-контейнеры и управляются оркестратором Kubernetes. Это дает автоматическое масштабирование: если нагрузка растет, Kubernetes сам поднимает новые копии нужного сервиса.
Главный вызов: Часовые пояса
Это тихий ужас любого глобального проекта. Решение одно и оно не обсуждается: на бэкенде все даты и время хранятся исключительно в UTC. Абсолютно все. А уже клиентское приложение отвечает за конвертацию в локальное время пользователя. Любой другой подход — гарантированная катастрофа в будущем.
В итоге, моя работа — не просто «кодить фичи». Это инженерия сложной, отказоустойчивой и быстрой распределенной системы, которая не ляжет в пиковые часы, когда тысячи людей по всему миру нажимают кнопку «Начать урок».
Архитектура: Прощай, монолит
Сразу было решено отказаться от монолита в пользу микросервисов. Такой сложный проект должен быть гибким и отказоустойчивым. Я разбил всю логику на независимые службы:
Auth Service: Контроль доступа (JWT, роли).
Scheduler Service: Мозг платформы. Жонглирует тысячами уроков, учитывая часовые пояса преподавателей из Бразилии и студентов из Владивостока.
Matching Service: Интеллектуальный подбор идеальной пары «ученик-учитель».
Billing Service: Управление подписками, платежами и зарплатами. Максимальная надежность.
Classroom Service: Дирижер урока, работающий в реальном времени.
Связь между ними — через асинхронную шину сообщений (вроде RabbitMQ), чтобы падение одного сервиса не повлияло на всю систему.
Сердце системы: Виртуальный класс
Интерактивный класс Vimbox — это самое сложное и интересное. Это stateful-приложение, где задержка недопустима.
Здесь я сделал ставку на WebSockets. Когда учитель рисует на виртуальной доске, его браузер не бомбит сервер запросами. Вместо этого между ним, сервером и учеником установлен постоянный канал. Клиент учителя отправляет событие (например, {"event": "draw", "coords": [x1, y1, x2, y2]}), мой сервис на Go ловит его и мгновенно пересылает ученику для отрисовки на его холсте. Весь процесс занимает миллисекунды, обеспечивая полную синхронизацию.
Видео и аудиопоток гонять через свои серверы — бессмысленная нагрузка. Для этого используется WebRTC, позволяющий браузерам общаться напрямую (peer-to-peer). Мой бэкенд лишь «знакомит» их, обеспечивая служебный сигналинг для установки соединения.
Технологии и инфраструктура
Стек подбирался под конкретные задачи для максимальной производительности:
Языки: Go для высоконагруженных сервисов реального времени (Classroom), Python (FastAPI) для остальной бизнес-логики.
Базы данных: PostgreSQL как основная реляционная база, Redis для кеширования всего и вся, а также как брокер для WebSockets.
Инфраструктура: Все сервисы упакованы в Docker-контейнеры и управляются оркестратором Kubernetes. Это дает автоматическое масштабирование: если нагрузка растет, Kubernetes сам поднимает новые копии нужного сервиса.
Главный вызов: Часовые пояса
Это тихий ужас любого глобального проекта. Решение одно и оно не обсуждается: на бэкенде все даты и время хранятся исключительно в UTC. Абсолютно все. А уже клиентское приложение отвечает за конвертацию в локальное время пользователя. Любой другой подход — гарантированная катастрофа в будущем.
В итоге, моя работа — не просто «кодить фичи». Это инженерия сложной, отказоустойчивой и быстрой распределенной системы, которая не ляжет в пиковые часы, когда тысячи людей по всему миру нажимают кнопку «Начать урок».
Алматы (Алма-Ата) 
Свободен для работы