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: санклисти/РЕР, джерело коштів, 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. На такому фундаменті платформа спокійно проживе піки турнірів, нові гео і десятки брендів - без ризику для грошей гравців і репутації.