Архитектура casino core: слои, модули, шины данных

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

💡 18+. Материал — просветительский. Не призыв к игре. Цель — показать инженерную «карту местности» для построения или аудита ядра iGaming.

1) Картина целиком: из чего состоит casino core

Casino core — это набор доменных сервисов, обеспечивающих регистрацию/идентификацию игроков, приём/хранение денег, расчёт ставок, бонусную экономику, контроль рисков и соответствие регуляторике. На схеме сверху вниз:

1. Edge-слой (внешний периметр): API-шлюз, WAF/бот-защита, rate limiting, сервис-mesh ingress, гео/юридические фильтры.

2. Domain-слой (бизнес-логика): PAM, Wallet/Ledger, Bonus Engine, Cashier/PSP Orchestration, Game Sessions, Risk/Anti-Fraud, RG, Jackpot/Tournaments, Affiliates, CRM/Notifications, Compliance/Reporting.

3. Data/Integration-слой: шины событий (Kafka/Pulsar), очереди (SQS/Rabbit), CDC/Outbox, ETL/ELT (в витрины BI), Feature Store/ML, кэши (Redis), OLTP БД (Postgres/Oracle), OLAP (ClickHouse/BigQuery).

4. Observability & SecOps: metrics/tracing/logs, SIEM/SOAR, секреты (Vault/HSM), ключи и токены, RBAC/ABAC, audit log (WORM).

2) Доменные модули (минимально необходимый состав)

2.1 PAM (Player Account Management)

Регистрация/логин, SSO, управление сессиями и устройствами, KBA/2FA.

Профиль: возраст/гео/валюта/сегменты, статусы RG/самоисключения.

Ограничения: доступ к играм по юрисдикции, баны, «реальность-чеки».

2.2 Wallet/Ledger (денежный контур)

Мультивалютные счета, двойная запись (debit/credit), неизменяемые проводки.

Атомарные транзакции ставок и выигрышей (idempotency keys, exactly-once внутри домена).

Холды под активные спины/раунды; транзитные счета джекпота.

Взаимодействие только через команды (command API), чтение — через проекции (CQRS).

2.3 Cashier / PSP Orchestration

Роутинг платежей по гео/бин-диапазонам/скорингу; каскадирование при отказах.

3-DS/AVS/velocity-правила; токенизация карт; on-/off-ramp для крипты.

Набор SLO: авторизация ≤ 3с p95, общий успех депозита ≥ 85% на гео.

2.4 Game Sessions (интеграции с провайдерами)

Создание игровых сессий (token handshake), валидация страны/валюты/возраста.

События ставкa→исход→сеттлмент идут по шине; RNG и расчёт — на стороне провайдера.

Анти-абьюз: min bet, частота спинов, запрет смены номинала «внутри трика».

2.5 Bonus Engine

Стейты бонуса (issued/locked/active/forfeit), вейджер, вклад по играм, max bet/max cashout, дедлайны.

Миссии/квесты, фриспины, кэшбэк; совместимость с турнирами/джекпотами.

Жёсткая валидность правил на момент ставки; неизменяемая история.

2.6 Risk / Anti-Fraud

Поведенческие сигналы (скорость ставок, мульти-аккаунты, общие устройства/карты).

Правила velocity, графовые проверки связей, chargeback defense.

Реакции: мягкие (лимиты), жёсткие (блок/эскалация в AML).

2.7 Responsible Gambling (RG)

Лимиты депозитов/потерь/ставок/времени, тайм-ауты, самоисключение.

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

2.8 Jackpots & Tournaments

Локальные/сетевые, фикс/прогрессив; долевой сбор с каждой ставкой.

Публичные лидерборды; независимая верификация итогов; анти-бот.

2.9 Affiliates & CRM

Трекинг суб-ID, атрибуция (CPA/RevShare/Hybrid), постбэки.

Сегментация, триггеры, suppression-правила, омниканал (push/e-mail/SMS).

2.10 Compliance & Reporting

Регуляторные выгрузки, налоговые отчёты, SAR/STR; аудит-лог WORM.

Data residency по юрисдикциям (EU/UK/BR и т. д.).

3) Событийная модель и шины данных

3.1 Базовые топики (пример Kafka-нейминга)

`player.registered`, `player.kyc.status.changed`

`wallet.debit.requested/committed/failed`, `wallet.credit.`
`game.session.started/ended`, `bet.placed`, `bet.settled`
`bonus.issued/consumed/forfeited`, `wager.progress.updated`
`rg.limit.hit`, `rg.timeout.started/ended`
`cashier.deposit.requested/succeeded/failed`, `withdrawal.requested/sent`
`risk.alert.raised/closed`, `aml.case.opened`
`jackpot.contribution/triggered`, `tournament.score.updated`

Контракты: Avro/JSON Schema + Schema Registry, versioning (backward compatible), строгие ключи идемпотентности.

3.2 Шаблон события (упрощённо)

json
{
"event_id": "uuid",  "event_type": "bet.settled",  "occurred_at": "2025-10-23T16:09:12Z",  "tenant_id": "brand-1",  "player_id": "p_123",  "session_id": "s_456",  "trace_id": "t_abc",  "payload": {
"game_id": "provider:slot_777",   "bet_amount": {"amount": 2.00, "currency": "EUR"},   "win_amount": {"amount": 36.40, "currency": "EUR"},   "bonus_impacted": true
}
}

Правило: события — неизменяемые; корректировки — отдельными компенсирующими событиями.

3.3 Outbox & CDC

Все доменные транзакции пишут событие в outbox в той же БД → фоновый паблишер отправляет в шину.

CDC (Debezium и аналоги) — для вторичных потоков в DWH без нагрузки на OLTP.

4) Консистентность, саги и идемпотентность

Саги для длинных процессов (депозит/кэшаут, верификация, турнирные награды).

Идемпотентность всех команд: `Idempotency-Key` + дедупликация на стороне сервиса.

Стратегия согласованности: в кошельке — строго (ACID), в остальном — eventual (через проекции).

Компенсации: отдельные доменные события, запрет «ручных правок» в леджере.

5) Данные: OLTP/OLAP, кэши, проекции

OLTP: Postgres/Oracle для кошелька, PAM, бонусов (p95 < 150 мс).

Кэши: Redis для сессий, лимитов, горячих проекций лидербордов.

OLAP: ClickHouse/BigQuery — витрины KPI (FTD, NGR, ARPPU, Retention, LTV, Wager progress, Risk flags).

Проекции (CQRS): быстрый поиск по игрокам/транзакциям (<2с), real-time панели RG/риск.

6) Платёжная оркестрация: детальнее

Правила роутинга: гео, BIN, риск-скор, нагрузка, стоимость.

Каскад: PSP1 → PSP2 без потери корзины; ретраи с экспоненциальной паузой.

Сверки: ежедневные отчёты PSP → реестр кошелька; авто-расхождения → тикеты.

7) Интеграции с провайдерами игр

Gateway-паттерн: единый Game API, маппинг валют/фичей, health-чек с деградацией.

Сеттлмент: входящий коллбек провайдера → доменная команда wallet.settle с ключом идемпотентности.

Блокировки: минимальные; ставка/выигрыш — атомарная пара проводок.

8) Наблюдаемость и SLO

Метрики: p95/p99 latency per service, error rate, saturation, business KPIs (bets/min, settle lag, deposit success).

Трассировка: trace_id сквозной (edge→домены→шина→консьюмеры).

Логи: структурированные, с редактированием PII.

SLO-минимум:

Аптайм ядра ≥ 99,95%
p95 кошелька < 150 мс
Потерянных/дублированных сеттлментов = 0
Время задержки событий до BI < 5 мин

9) Безопасность и соответствие

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

Секреты: Vault/HSM, ротация ключей, KMS-шифрование данных «at rest».

PCI DSS / GDPR / локальные аналоги: сегментация сред, токенизация PAN, DLP, журнал доступа (WORM).

WAF/бот-защита: фильтры по поведенческим сигналам, device-fingerprinting.

Data residency: шардирование по регионам; запрет кросс-региональных PII.

10) Доступность, DR и версия релизов

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

Канареечные релизы/feature-флаги, откаты; миграции БД — через ghost/вторичные индексы.

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

11) Управление схемами и качеством данных

Data contracts: версионирование событий (semver), контрактные тесты продюсеров/консьюмеров.

Говеранс: каталог данных (data catalog), уровень доверия к источникам, SLA обновления витрин.

Качество: дедупликация, поздние события (late arrivals), idempotent upserts в OLAP.

12) Роли и доступы (Back-office)

RBAC: чёткие роли (финансы, риск, саппорт, маркетинг, комплаенс).

Крит-действия: подтверждения «4 глаз», журнал неизменяемых операций.

PII-экран: маскирование; полный доступ — по заявке/временным токенам.

13) Метрики зрелости casino core (самооценка)

1. Надёжность: SLO кошелька/кассы/сессий выполняются ≥ 99% дней.

2. Данные: события попадают в BI ≤ 5 мин; консистентность ledgers vs PSP ≥ 99,99%.

3. Бонусы: конструктор правил без правок БД; аудит изменений.

4. RG/AML: real-time сигналы; отчёты/выгрузки автоматизированы.

5. Инциденты: MTTR < 30 мин; постмортемы публичны внутри компании.

6. Тестирование: контрактные, нагрузочные, хаос-тесты; тестовые песочницы провайдеров/PSP.

14) Чек-лист аудитора архитектуры

Есть outbox/CDC, событие публикуется атомарно с транзакцией.
Леджер реализован как неизменяемая книга проводок; есть сверка с PSP.
Все команды идемпотентны; есть дедупликация на ключах.
Разделены OLTP и OLAP; проекции не бьют по боевым БД.
RG-лимиты применяются синхронно при ставке; reality-check принудителен.
Game gateway деградирует до read-only/«no new sessions» при инцидентах.
DR-план регулярно упражняется; бэкапы проверяются восстановлением.
Политика ключей/секретов и их ротации задокументирована.
Compliance-отчёты собираются автоматически (без Excel-ручного труда).
Логи аудита — WORM, доступ по принципу наименьших прав.

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

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

Смешение публичного и приватного API, отсутствие API-шлюза.

Запись событий «в обход» транзакций домена (не через outbox).

Монолитный кошелёк и бонусы без идемпотентности и саг.

Единая БД «на всё» + BI-запросы по боевой схеме.

Отсутствие версионирования событий и контрактных тестов.

Нет реестра изменений правил бонусов и турнирных формул.

Платёжные отказы без каскада; «попробуйте позже» как стратегия.

Нет RG-инструментов «из коробки»; лицензия на доверии.

Casino core — это событийная, строго лимитированная по правам «сеть» сервисов, где деньги и ответственность первичны. Сильная архитектура держится на трёх столпах:

1. Жёсткая целостность денег (ledger, идемпотентность, саги, outbox/CDC), 2. Событийность и наблюдаемость (контракты, трассировка, SLO, BI-витрины), 3. Безопасность и комплаенс по умолчанию (zero-trust, PCI/GDPR, RG/AML).

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