Torrent Gear

Как обеспечить масштабируемость платформы казино

Полный текст статьи

💡 18+. Технический материал для продуктовых и инженерных команд iGaming. Не призыв к игре.

1) Что именно должно масштабироваться

Трафик и сессии: всплески из SEO/стримов/турниров (десятки тысяч RPS на чтение, тысячи RPS на запись).

Денежный контур: ставки/сеттлменты/депозиты/кэшауты — приоритет целостности и латентности.

Платежи: маршрутизация по PSP, каскады, разные гео и мерчанты.

Контент: сотни провайдеров, десятки тысяч игровых сессий параллельно.

Данные: real-time витрины KPI и отчётность, не блокируя OLTP.

Комплаенс: RG/AML/KYC в реальном времени.

2) Архитектурные основы масштабируемости

2.1 Слои и разделение ответственности

Edge: API-gateway, WAF/бот-защита, rate-limit, geo-фильтры.

Доменные сервисы: Wallet/Ledger, Cashier, Game Gateway, Bonus, RG, Risk/AML, PAM, Affiliates, CRM.

Data-слой: шина событий (Kafka/Pulsar), очереди (SQS/Rabbit), кэши (Redis), OLTP (Postgres/Oracle), OLAP (ClickHouse/BigQuery).

Observability/SecOps: метрики/трейсы/логи, SIEM/SOAR, Vault/HSM.

2.2 Событийная модель + CQRS

Команды (записи) — строго через доменные API;

Чтение — через проекции (индексированные представления/кэши/OLAP).

Outbox/CDC: каждое событие публикуется атомарно с транзакцией; аналитика «слушает» шину, а не боевую БД.

2.3 Саги и идемпотентность

Длинные процессы (депозит, кэшаут, бонус, турнирные награды) — оркестрируются сагами.

Все денежные и бонусные команды — идемпотентны (Idempotency-Key + дедупликация).

3) Масштабирование денежных путей (№1 по приоритету)

3.1 Ledger как отдельный сервис

ACID-БД с двойной записью (debit/credit), неизменяемые проводки, аудит-лог WORM.

p95 кошелька < 150 мс, «потерянных/дублированных сеттлментов» = 0.

3.2 Кэш-вспомогательные, но не «истина»

Redis для лимитов, балансов-проекций, локов на коротких участках; кошелёк остаётся источником правды.

Защита от cache stampede (TTL+jitter, single-flight).

3.3 Горизонтальное масштабирование

Шардирование по player_id/brand_id/region, горячие шарды — на отдельные узлы.

Read-replicas для проекций/бэк-офиса; OLTP ↔ OLAP разделены.

4) Платежи и оркестрация PSP на росте

Routing: по BIN/гео/скорингу/стоимости; динамическая переоценка каналов.

Каскадирование: отказ PSP1 → PSP2 без потери корзины (идемпотентные токены).

3-DS/AVS/velocity-правила у входа; антифрод с графовыми связями карт/устройств.

Сверки: авто-сопоставление реестров PSP и леджера ежедневно; алерты по расхождениям.

5) Game Gateway и «взрывы» нагрузки

Единый шлюз к провайдерам (token-handshake, health-чек, деградация «no new sessions»).

Back-pressure и очереди на сеттлмент, чтобы провайдерские пики не клали кошелёк.

Rate-limit на уровень игрока/стола/провайдера; защита от «внутриигровых триков».

6) Данные и аналитика без удушения продакшена

Outbox/CDC → стрим в DWH, SLA доставки витрин ≤ 5 мин.

Проекции KPI (FTD, NGR, ARPPU, Retention, LTV, Wager Progress, Risk flags) — в OLAP.

RLS/маскирование PII в хранилище; PII держим регионально (data residency).

7) Multi-region / Multi-brand

7.1 Географическая устойчивость

Актив-актив/актив-пассив по регионам, RPO ≤ 5 мин, RTO ≤ 30 мин.

Гео-шардирование PII/денег (EU/UK/BR/…); запрет кросс-регионных запросов к PII.

7.2 Мультибренд

Общие интеграции (Game Gateway, Bonus, Affiliates) + изолированные Ledger/Cashier/PII per лицензия/регион.

В шине событий обязательные ключи `tenant_id/brand_id/license`.

8) Наблюдаемость, надежность, хаос-инжиниринг

Метрики: p95/p99 latency per service, error rate, saturation, бизнес-метрики (bets/min, settle lag, deposit success).

Трейсинг: единый `trace_id` через edge → домены → шину → консьюмеры.

Алертинг по SLO: SLO-бюджет ошибок и управляемые деградации (заморозка бонусов, stop-new-sessions).

Хаос-практики: регулярные фейлы PSP/провайдеров/сети, проверка каскадов и саг.

9) RG/AML/KYC в масштабе

Синхронные стоп-сигналы на ставке (лимиты депозита/потерь/времени, самоисключение).

Потоки поведенческих сигналов (длинные сессии, эскалация ставки), проактивные нотификации.

AML: санклисты/PEP, источник средств, SAR/STR — автоматизированные пайплайны.

10) Безопасность «по умолчанию»

Zero-trust: mTLS, короткоживущие токены, RBAC/ABAC, принцип наименьших прав.

Секреты — Vault/HSM; KMS-шифрование at-rest, токенизация PAN (PCI DSS).

WAF/бот-защита, device-fingerprinting, DLP; неизменяемый аудит (WORM).

11) FinOps для масштабируемости без разорения

Автоскейл по бизнес-метрикам (bets/min, settle lag), а не только по CPU.

Spot/прерываемые инстансы — для асинхронных консьюмеров и ETL.

Лимиты квот, бюджетные алерты; тэгирование затрат по сервису и бренду.

Профилирование запросов/индексов; TTL-политики на логи/метрики.

12) Дорожная карта эволюции (если старт с монолита)

1. Ввести шину событий и единый словарь (`bet.placed`, `bet.settled`, `wallet.debit/credit`, `deposit.succeeded`).

2. Вынести Ledger в отдельный сервис/БД с outbox и идемпотентностью.

3. Отделить Cashier (PSP-оркестрация, каскады, сверки).

4. Поставить Game Gateway и деградации «no new sessions».

5. Перевести Bonus/RG на подписку событий; запретить ручные правки.

6. Разнести OLTP/OLAP и настроить CDC-потоки в DWH.

7. Включить observability (SLO-дашборды, трассинг) и хаос-учения.

8. Подготовить multi-region (данные/ключи/мерчанты/PII) — по гео приоритетам.

13) SLO-минимум для зрелой платформы

Аптайм ядра (Wallet/Cashier/Game Gateway) ≥ 99,95%.

p95 Ledger < 150 мс; авторизация Cashier < 3 с; успех депозита ≥ 85% в целевом гео.

«Потерянных/дублированных сеттлментов» = 0.

Доставка событий до BI ≤ 5 мин.

MTTR инцидентов ядра < 30 мин.

14) Чек-лист архитектора масштабируемости

Домены разделены; деньги — отдельный Ledger с outbox/CDC.
Команды идемпотентны; ключи дедупликации повсюду.
Game Gateway с back-pressure и режимом деградации.
Cashier: каскады PSP, ретраи, сверки, телеметрия отказов.
CQRS/проекции; OLTP и OLAP физически разделены.
Шина событий со Schema Registry; версионирование контрактов.
RG/AML — синхронные стоп-сигналы; логи и отчёты автоматизированы.
Observability: метрики/трейсы/логи с `trace_id` и тегами brand/tenant.
DR-план: актив-актив/пассив, RPO ≤ 5 мин, RTO ≤ 30 мин; регулярные учения.
Безопасность: mTLS, Vault/HSM, PCI/GDPR, WAF/бот-защита, WORM-аудит.
FinOps: автоскейл по бизнес-метрикам, бюджет-алерты, тэги затрат.

15) Анти-паттерны (красные флаги)

Единая БД «на всё», BI бьёт по боевым таблицам.

Ручные правки балансов/бонусов в БД.

Публикация событий «в обход» транзакции (нет outbox).

Отсутствие деградаций: «или всё, или падаем».

Платёжные отказы без каскадов и телеметрии.

Нет идемпотентности; ретраи создают дубли сеттлментов.

Отсутствие гео-изоляции PII и ключей мерчантов.

Нулевая трассировка: расследования длятся часами.

Масштабируемость казино-платформы — это не «больше серверов», а правильные границы и событийная операционная модель: изолированный и быстрый денежный контур, устойчивый платёжный слой, шлюз к играм с управляемой деградацией, разделение OLTP/OLAP, наблюдаемость и дисциплина SRE/FinOps. На таком фундаменте платформа спокойно проживёт пики турниров, новые гео и десятки брендов — без риска для денег игроков и репутации.