Архітектура 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), валідація країни/валюти/віку.

Події stavka→iskhod→settlment йдуть по шині; 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→domeny→shina→konsyumery).

Логи: структуровані, з редагуванням 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).

Побудувавши ці підстави, оператор масштабує контент, бонусну економіку і маркетинг без ризику для головного - грошей гравців і репутації бренду.