Чому важливе масштабування інфраструктури

Навіщо бізнесу масштабування

Виручка без «стелі». Пікові події (дербі, фінали, великі релізи слотів) кратно підвищують RPS. Масштабованість перетворює сплески трафіку в зростання GGR, а не в помилки 5xx.

Стабільні SLO. Тримаємо p95 латентності критичних шляхів (ставка, оновлення балансу, виведення) в цільових рамках при будь-якому онлайні.

Вартість під контролем. Еластичність = платимо за «гарячі години», а не за «постійний максимум».

Регуляторика і бренд. Доступність і передбачувана робота каси/гаманця - предмет аудиту і довіри гравців.

Типи масштабування

Горизонтальне (scale-out)

Додаємо екземпляри сервісів. Основа для stateless-API, bridge до провайдерів, веб-шлюзів, воркерів. Плюси: відмовостійкість, еластичність. Мінуси: потрібні ідемпотентність і зовнішній стан.

Вертикальне (scale-up)

Збільшуємо ресурси вузла. Підходить для БД і OLAP-кластерів, але має межу і дорожче на одиницю приросту.

Географічне

Multi-AZ і, при необхідності, multi-region: ближче до гравця → нижче затримка для ставок/стрімів і більше стійкість до аварій.

Що саме масштабується в казино

Edge и API: шлюзи, WAF, GraphQL/REST, WebSocket-хаби (ставки/події).

Bridge до провайдерів: адаптери live/RNG з HPA по RPS і часу до'bet. accepted`.

Гаманець/леджер: stateful-ядро - масштабування через репліки для читання, шардування та оптимізацію транзакцій.

Каса: окремі пули під провайдерів платежів/крипто on/off-ramp, черги для виплат.

Черги/шина подій: Kafka/NATS кластера з autoscaling consumers.

Кеш/каталоги: Redis/Memory-кешування гарячих ключів, CDN для статичних асетів.

Стрімінг: WebRTC/LL-HLS edge-ноди з автофолбеком і автоскейлом по QoS.

Інженерні принципи

1. Ідемпотентність у грошах. Будь ретрай по'bet. place`/`payout. request'обробляється рівно один раз (ключ ідемпотентності).

2. Черги та backpressure. Критичні шляхи не блокуються: якщо провайдер/БД зволікає, запити потрапляють в буфер з контрольованим «зливом», другорядні фічі деградують першими.

3. Кеш спочатку. Read-heavy запити (баланс, лобі) - через кеш/матеріалізовані уявлення; інвалідація - за подіями.

4. Шардування. Розділяємо дані/потоки (по'playerId', країні, провайдеру, валюті).

5. Консистентність там, де гроші. Суворе ACID тільки для гаманця/леджера; решта - eventual через події.

6. Спостережуваність до релізу. Метрики/трейси - частина контракту сервісу, інакше автоскейл «сліпий».

Метрики та цілі (SLO/SLA)

Латентність p95/p99:

`bet. place'≤ 150-250 мс (всередині регіону),'wallet. debit/credit` ≤ 50–100 мс, `payout. quote/submit` ≤ 500–800 мс.
Частка помилок: `5xx` < 0. 1–0. 3% на API,'reject _ rate'ставок <0. 2% при нормальній роботі.
Пропускна здатність: RPS на API/bridge; events/sec на шині.
Черги: довжина і час очікування (наприклад, виплати ≤ 2-5 хв в години пік).
QoS стріму: dropped frames, RTT сигналів ставок, аборт раундів.
Кеш-хіти: hit-ratio> 85-95% на гарячих ключах.
Cost/Revenue: вартість інфраструктури/GGR, вартість запиту (μ $ per call).

Корисна евристика (спростивши закон Літтла): середній час в системі ≈ довжина черги/пропускна здатність. Якщо при піку черга росте, збільшуйте consumers або знижуйте вхідний потік.

Патерни масштабування по доменах

Гаманець і леджер

Reader-replicas для читання; writer - один на шард.

CQRS: запис (строго) окремо від читання (матеріалізовані зрізи).

Batch-звірка і «підправляючі» транзакції - строго через append-only журнал.

Bridge/ігрові інтеграції

Stateless-адаптери з автоскейлом по latency of'bet. accepted`.

Circuit breaker на кожного провайдера, при деградації - тимчасова деградація UI і відключення столів.

Платежі/крипта

Виділений пул під webhook'і PSP/on-chain слухачів; повторна обробка за idempotency.

Маршрутизатор по провайдерам на основі SLA/вартості/країни.

Навантажувальні операції

Воркери/джоби (бонуси, місії, турніри) - у чергах; масштабуються по довжині черги і дедлайнах.

Стрімінг

Edge-пули на регіони, автофолбек WebRTC → LL-HLS; вертикальні ліміти на бітрейт/якість для утримання QoS.

Архітектурні рішення

HPA/VPA/Cluster Autoscaler: HPA — на API/bridge; VPA - на ETL/звіти; вузли - різнотипні пули (CPU-heavy, memory-heavy, network-optimized).

PodDisruptionBudget і пріоритети: ядро грошей захищене від витіснення.

Feature flags і канарські релізи: масштабуємо нові фічі на відсотках трафіку.

Geo-routing: Anycast/DNS і регіональні ingress-шлюзи - ближче до користувача.

Вартість та ефективність

Профілі ресурсів. Requests/limits задані і відповідають реальному профілю (без CPU-throttling на критичних шляхах).

Спотові пули для аналітики/ETL і фонових джоб.

Автовиключення тестових/стейдж оточень поза робочим вікном.

Кеш замість ядер. Дешевше додати Redis-хіти, ніж множити CPU на БД.

Безпека при масштабуванні

mTLS/mesh між сервісами при зростанні графа викликів.

Сегментація мережі (NetworkPolicy): домени грошей/PII - окремі зони довіри.

Ротація секретів і підпис образів - більше вузлів = більше місць ризику.

Контроль blast-radius: шардування і ліміти запитів захищають від каскаду.

Анти-патерни

Масштабувати моноліт з глобальними блокуваннями: зростання подів = зростання конфліктів.

Гріти кластери назавжди «на пік», замість HPA і деградації «другорядних» фіч.

Змішувати OLTP і OLAP на одній БД - будь-який звіт вбиває затримки ставок.

Відсутність ідемпотентності - дублі дебету при ретраях (особливо на піку).

Сліпий автоскейл по CPU - ігнорує реальну метрику (час'bet. place', довжина черги).

Один провайдер платежів на країну - масштабувати нічого, коли він «лежить».

Чек-лист впровадження масштабування

Стратегія

Визначені SLO (p95 латентності, помилки, RPS) і бюджет помилок.
Сегментація доменів: гроші/ставки/каса - окремо від другорядних фіч.

Дані

Шардування/репліки, CQRS на читання, матеріалізовані уявлення.
Кеш-шар з чіткою політикою інвалідації.

Інфраструктура

HPA/VPA, різні node-пули, PDB і пріоритети.
Geo-routing, multi-AZ, готовність до DR.

Програми

IdempotencyKey на гроші/виплати/вебхуки.
Circuit breakers і таймаути; backpressure/черги.
Feature flags і канарка.

Спостережуваність

Трейси наскрізні (ingress → API → гаманець → провайдер → webhook).
Дашборди RPS/latency/errors/queues/QoS стріму.
Алерти на зростання'reject _ rate'і деградацію'round. settle`.

Вартість

Правильні requests/limits, споти для фонових завдань, авто-sleep не-prod.

Масштабування інфраструктури - це не про «більше серверів». Це про керовану еластичність: де потрібна жорстка консистентність (гроші) - ми проектуємо шард-ядро і швидкі транзакції; де можна - переносимо на події, черги і кеші. Додайте до цього спостережуваність, географію і дисципліну релізів - і платформа витримає будь-який пік без компромісів по SLO, P&L і довіри гравців.