Розбір проєкту / розбір проєкту
GrandCombat: як розбирати масштабування backend Telegram Mini App
У Telegram-грі швидкість екрана залежить від того, що відбувається після кожної дії користувача. На прикладі GrandCombat розглядаємо, які частини backend варто аналізувати окремо і як перетворити очікуваний онлайн на перевірювані сценарії.
Що відомо з опублікованого кейсу
До scope GrandCombat MiniApp входили onboarding, завдання, нагороди, прогрес, referrals і TON Connect. На backend — архітектура під високий онлайн, кешування, черги, Socket.IO, аналітика та контроль навантаження. У стеку вказані NestJS, MongoDB і Redis.
Цей матеріал спирається на публічний опис проєкту. Топологію інфраструктури, розмір інстансів, схеми колекцій та результати профілювання тут не розкрито. Подальші приклади — наші інженерні рекомендації для подібних задач, а не реконструкція непублічного production-коду.
Розділити підтвердження дії та її наслідки
Для гри корисно окремо описати перевірку права на дію, фіксацію результату та супутню роботу. Винагорода не повинна залежати від того, чи встиг оновитися аналітичний звіт. Водночас інтерфейс не має показувати остаточний успіх до серверного підтвердження.
На проєктуванні ми складаємо список операцій, для яких повтор запиту небезпечний: видача нагороди, referral-бонус, зміна балансу. Для них потрібен узгоджений спосіб розпізнати ту саму дію та не застосувати її двічі.
text
Дія в Mini App → перевірка сесії та правил → запис результату
→ відповідь користувачу
→ фонові наслідки й аналітика
Ілюстративна схема відповідальностей, не production-схема GrandCombat.Що кешувати, а що залишати джерелом істини
Перший кандидат для кешу — інформація, яку часто читають і для якої зрозуміла допустима затримка оновлення. Умови завдання та персональний результат його виконання мають різні вимоги. Кеш не повинен самостійно вирішувати, чи дозволено повторно отримати винагороду.
| Категорія | Питання до проєктування |
|---|---|
| Каталог завдань | Як швидко адміністраторська зміна має стати видимою? |
| Прогрес користувача | Який запис підтверджує завершення дії? |
| Таблиця лідерів | Чи допустима затримка й чи показує інтерфейс час оновлення? |
| Сесія | Що відбувається після відкликання доступу або завершення строку дії? |
Черги та real-time потребують окремих сценаріїв відмови
Фонова задача повинна мати власника, обмеження повторів і спосіб побачити остаточну помилку. Ідемпотентність означає, що повтор задачі не змінює кінцевий результат додатковий раз. Це особливо важливо для операцій, які мають бізнес-наслідки.
Для real-time інтерфейсу варто перевірити втрату з'єднання та повернення користувача. Після відновлення клієнт має отримати актуальний стан, а не покладатися лише на події, які могли пройти під час розриву.
Як підготувати тест перед новою кампанією
Одна цифра одночасних користувачів не описує навантаження. Ми пропонуємо розділити вхід, читання прогресу, активні дії, завершення завдань і повторне підключення. Для кожного потрібні очікувана частота, допустимий час відповіді й умова успіху.
- Перевірити хвилю входів після повідомлення в Telegram.
- Повторити одну дію кілька разів і перевірити кінцевий стан.
- Затримати фонову обробку та переконатися, що команда бачить проблему.
- Відключити й відновити real-time з'єднання без втрати прогресу.
- Зіставити помилки API, час відповіді та затримку черги з конкретним сценарієм.
Джерела та контекст
Маєте подібну задачу?
Розкажіть про продукт, поточні обмеження й потрібний результат — визначимо предметний наступний крок.