582
Початок навчального року, запуск великого розпродажу, масовий вебінар — для EdTech-платформи з мільйонами зареєстрованих акаунтів кожна з цих подій означає різке зростання навантаження. Понад 100 тисяч користувачів одночасно звертаються до сервісу, генеруючи десятки тисяч запитів на секунду — тих, що потребують миттєвої відповіді (завантаження сторінки, пошук, оплата), і тисячі фонових операцій (обробка файлів, надсилання сповіщень, індексація контенту). Здатність інфраструктури витримати подібний тиск залежить від якості архітектурних рішень, закладених задовго до пікового моменту.
Eduki — міжнародна EdTech-платформа з понад 3,4 мільйона зареєстрованих користувачів у 27 країнах світу. На платформі розміщено більше ніж 1,5 мільйона унікальних цифрових навчальних матеріалів, які створюють понад мільйон авторів-викладачів. Стабільна робота сервісу такого масштабу вимагає інженерних рішень рівня великих e-commerce платформ.
Віталій Ліневич, Full-Stack Software Engineer в Eduki, — один із інженерів, чия робота безпосередньо визначає архітектурну стійкість цього продукту.
У цьому матеріалі розглянемо конкретні інженерні рішення, які дозволяють платформі залишатися доступною навіть у пікові моменти, та роль, яку відіграє один інженер у побудові інфраструктури для мільйонів.
Двошарова модель навантаження
Платформа працює у режимі двошарового навантаження. Перший шар — синхронний: HTTP-запити від користувачів, що потребують миттєвої відповіді при відкритті сторінки, пошуку матеріалу чи переході до оплати. Другий шар — асинхронний: операції, які можуть виконуватися у фоновому режимі — завантаження файлів, обробка платежів, надсилання сповіщень, індексація контенту. Чітке розмежування цих потоків дає змогу системі залишатися доступною навіть у пікові моменти.
На момент приєднання Ліневича до Eduki перехід від синхронної обробки важких операцій до event-driven архітектури з чергами повідомлень уже був серед стратегічних пріоритетів команди, і перші кроки в цьому напрямі було зроблено. Інженер долучився до проєкту на визначальному етапі й зробив вагомий внесок у повноцінну реалізацію переходу — рішення, яке CTO Eduki охарактеризував як таке, що встановило стандарт для подальших змін на рівні платформи. До цієї зміни генерація документів, надсилання нотифікацій та обробка завантажень виконувалися в рамках одного HTTP-запиту. У пікове навантаження це призводило до таймаутів і деградації сервісу для всіх користувачів одночасно. Після впровадження асинхронної моделі через RabbitMQ (брокер повідомлень, який дозволяє розподіляти завдання між різними сервісами) операції стали миттєвими з погляду кінцевого користувача: він отримує підтвердження дії, а реальна обробка відбувається у фоновому режимі. Таким чином на практиці платформа обробляє десятки тисяч запитів на секунду по основному шару і тисячі фонових повідомлень на секунду через брокер черг, і залишається доступною. До впровадження event-driven моделі аналогічне навантаження призводило до масових таймаутів, які впливали на всіх користувачів платформи одночасно.
Горизонтальне масштабування та оркестрація
Мікросервісна частина платформи працює в середовищі, яке автоматично реагує на зміну навантаження: за зростання кількості користувачів система самостійно запускає додаткові копії потрібних сервісів, а за спаду — вивільняє ресурси. Це відбувається на основі показників використання процесора та пам’яті, без втручання інженера в реальному часі. Монолітна частина платформи масштабується за тим самим принципом, проте потребує більше ресурсів через свою архітектуру — єдиний великий модуль складніше «розмножити», ніж окремі незалежні сервіси.
Додатково навантаження знижується завдяки кешуванню на кількох рівнях, від зберігання часто запитуваних даних у пам’яті до кешування контенту через мережу доставки (CDN), а також розподілу читання бази даних між кількома копіями-реплікам, що запобігає перетворенню бази на вузьке місце системи.
Динамічне масштабування обробників черг
Ще один рівень оптимізації стосується фонових завдань — тих операцій, які виконуються «за лаштунками». Система автоматично відстежує, скільки таких завдань накопичилося в черзі, і запускає додаткові процеси-обробники за потреби. Після нормалізації навантаження зайві обробники вимикаються. Завдяки цьому платформа справляється з різкими сплесками активності (наприклад, на старті навчального року) без постійного утримання надлишкових серверних потужностей.
“Архітектура програмного забезпечення — це передусім про те, як система поводиться під навантаженням у реальних умовах. Правильне проєктування закладає можливість змінювати та розширювати платформу без необхідності повного переписування коду. Така здатність до еволюції відрізняє стійкий продукт від тимчасового рішення”, — зазначає Віталій Ліневич.
Стратегічна роль інженера в довгостроковій стабільності продукту
Робота інженера у системі такого масштабу не може обмежуватися написанням коду. За оцінкою CTO Eduki, Віталій Ліневич працює як інженер, відповідальний за цілісні напрямки продукту. Від нього очікується розуміння бізнес-контексту технічних рішень, самостійне пропонування архітектурних підходів і відповідальність за кінцеві результати. Його участь у технічному плануванні безпосередньо впливає на визначення пріоритетності ринків і послідовність масштабування платформи.
На практиці оцінка технічної здійсненності та складності впровадження, яку надає Віталій, формує рішення на рівні бізнес-стратегії компанії. Eduki, що існує на ринку понад 10 років і налічує 138 співробітників, залежить від точності таких оцінок при плануванні міжнародного розширення.
Конкретний приклад: рішення про послідовність виходу на нові ринки. Платформа розширилася з трьох європейських країн (Німеччина, Іспанія, Франція) до 27 ринків на кількох континентах, включаючи Латинську Америку та Азію. Саме Віталій Ліневич був головним інженером, відповідальним за проєктування інфраструктури цієї мультиринкової експансії. Його оцінка технічної складності та порядку інтеграції окремих ринків безпосередньо впливала на те, яким країнам надавався пріоритет. Після розгортання до платформи приєдналося понад 200 тисяч нових користувачів з нових ринків, а міжнародна експансія принесла понад 1,55 мільйона євро додаткового доходу.
Історія Eduki лише підтверджує, що масштабованість досягається системним підходом до архітектури, від асинхронної обробки до динамічного масштабування обробників, від стратегії кешування до розподілу навантаження на базу даних.
“Справжній Full-Stack інженер проєктує межі того, як система витримує мільйони користувачів. Рішення, закладені сьогодні, визначають, чи зможе продукт рости завтра без радикальної перебудови”, — підсумовує Віталій Ліневич.
Автор: Павло Петренко
