Почему важно масштабирование инфраструктуры

Зачем бизнесу масштабирование

Выручка без «потолка». Пиковые события (дерби, финалы, крупные релизы слотов) кратно повышают 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 и доверию игроков.