Чому казино переходять на модульну архітектуру

Навіщо казино модульність

Історичний моноліт гальмує зростання: кожна зміна тягне реліз всієї системи, інтеграції провайдерів і PSP б'ють по SLO, комплаєнс-апдейти - по всьому коду. Модульна архітектура (domain-driven + контрактні API + події) дозволяє:

Швидко виводити фічі і підключати провайдерів без координації «всіх з усіма»;
Масштабувати вибірково (live-відео окремо від каси, гаманець окремо від каталогу ігор);
Ізолювати ризики (помилка в промо не валить гаманець);
Дотримуватися ліцензії (логування/версії/політики в доменних межах);
Знизити TCO за рахунок чітких контрактів, повторного використання і автоматизації.

Карта доменів (приклад розбивки)

Wallet/Ledger - гроші, хедж валют, бонусні баланси, PITR, аудит.

Cashier/Payments - PSP, он-рамп/офф-рамп, KYT, ідемпотентні вебхуки.

Gaming Bridge - адаптери провайдерів, нормалізація round/bet.

Catalog/Lobby - ігри, провайдери, фічерінг і правила показу.

Promo/Bonus - правила акцій, ваучери, wager.

KYC/AML/RG - перевірка особи, санкції/РЕР, ліміти і самовиключення.

Experience - фронтенд, CDN, i18n, A/B, Telegram WebApp.

Telemetry/Analytics - події, вітрини, ML/ШІ.

Compliance & Audit - звіти MGA/UKGC, WORM-архів.

💡 Кожен модуль має власну схему даних, API і подієвого контракту; взаємодія - через шину подій і строго версіоновані інтерфейси.

Принципи модульної архітектури

1. DDD-межі (bounded context). Чітке володіння даними і логікою.

2. API-перший + події. OpenAPI/AsyncAPI, JSON-Schema, контрактні тести.

3. Версіонування та сумісність.'v1 → v1. 1 → v2` (expand→migrate→contract).

4. Idempotency & Exactly-once-intent. Ключі запитів, дедуплікація подій.

5. Безпека за замовчуванням. mTLS, HMAC-підписи, короткі JWT, RBAC/ABAC.

6. Незалежні релізи. Канарний/blue-green деплою, міграції «двописником» заборонені.

7. Спостережуваність. Наскрізний'traceId', метрики SLO на модуль.

8. Фіча-прапори. Трафік/гео/юзер-сегменти, безпечні відкати.

Шар інтеграції: як підключати провайдерів і PSP

Adapter/Bridge-патерн: кожен провайдер ігор/платежів - плагін з єдиним контрактом платформи.

Ігри: нормалізація'roundId/betId/status', маппінг помилок, кеш лімітів.

Платежі: єдиний інтерфейс'authorize/capture/refund/payout', вебхуки з ідемпотентністю.

Вимкнення: несправний адаптер переводиться в maintenance без впливу на інші.

Приклад контракту (фрагмент OpenAPI):

yaml post /wallet/debit:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/DebitRequest@v1'
responses:
'200': { $ref: '#/components/schemas/DebitResult@v1' }
'409': { description: IDEMPOTENT_REPLAY }

Події як «кровоносна система»

Шина (Kafka/NATS) → події:

`bet. placed`, `round. settled`, `payout. requested/approved`, `kyc. verified/failed`, `rg. limit_set`, `bonus. issued/consumed`, `cashier. webhook. received`, `wallet. hold/release`, `alert. slo_breach`.

Правила:

Події не скасовують минуле; коригування - окремими компенсуючими подіями.
Кожен модуль пише тільки свої вихідні події, похідні - як нові теми.

Дані: шари та узгодженість

OLTP на модуль: Postgres/MySQL/KeyDB - ізольовані транзакції.

OLAP/вітрини: ClickHouse/BigQuery будуються з подій; OLTP і аналітику не змішуємо.

Feature Store/ML: незалежний від OLTP шар з версіями фіч і TTL.

Узгодженість: стратегічно eventual між модулями, а для грошей - локальні ACID + ідемпотентні дії на кордонах.

Деплою і масштабування

Контейнери (Docker/K8s): автоскейл по модулю (wallet - CPU/IO; live-відео - мережа; bridge — RPS).

Ізоляція периметра: мережеві політики, окремі секрети/ключі на модуль, різні сховища PII/грошей/телеметрії.

Трафік-шейпінг: фіча-прапори, канарська частка, регіональні маршрути.

DR/HA: Multi-AZ; актив-пасив для грошей, актив-актив для читань/медіа.

Комплаєнс «вшитий» в модулі

KYC/AML/RG - власний модуль з політиками і журналом рішень ('policyVer').

Audit/WORM - незмінне сховище подій грошей/раундів/виплат.

Звітність - експорт по юрисдикціях (MGA/UKGC), SLA на повноту/своєчасність.

Зразок потоків

Ставка → розрахунок → виплата

1.'gaming-bridge'відправляє'bet. placed` (idempotent).

2.'wallet'робить'hold'і публікує'wallet. hold`.

3.'gaming-bridge'отримує результат провайдера →'round. settled`.

4.'wallet'вважає'settle'( release/payout) →'wallet. settled`.

5.'promo'споживає події і нараховує бонус →'bonus. issued`.

Каса (депозит)

1.'cashier'створює'payment. intent` с `Idempotency-Key`.

2. PSP кличе вебхук →'cashier. webhook. received`.

3. `wallet. credit'за фактом → подія для аналітики і RG.

Зміни без простою (expand→migrate→contract)

1. Expand: додали поля/ендпоінт в'v1. 1', старі клієнти не ламаються.

2. Migrate: споживачі читають нове, пишуть в обидві версії (dual-write тільки для не-грошових).

3. Contract: оголосили EOL'v1. 0', видалили через N тижнів за планом.

Платформна інженерія

Golden Paths: шаблони модулів (repo-аскелеон, CI/CD, алерти, SLO, секрети).

Контрактні тести: Pact/AsyncAPI tests в CI; середовище інтеграцій з фейк-провайдерами.

Каталог сервісів (Backstage): хто власник, SLA, версії API, інцидент-рукбуки.

Метрики успіху модульності

Lead time від ідеї до прод-релізу ↓ в X раз.

Частота релізів по модулю ↑ (в день/тиждень), change-fail rate ↓.

MTTR щодо інцидентів ↓ (через ізоляцію).

Infra cost/GGR стабільний або ↓ при зростанні трафіку (виборчий скейл).

Час інтеграції провайдера/PSP (від брифінгу до прод) ↓.

Анти-патерни

«Мікросервіси заради мікросервісів». Без чітких меж даних зростає зв'язність і складність.

Загальні БД/схеми між модулями. Вбиває ізоляцію і незалежні релізи.

Події без версії/контракту. Ламають споживачів «тихо».

Dual-write для грошей. Ризик неузгодженості - тільки ідемпотентні кроки через один письменник.

Глобальний «утиліті-шар» з усім підряд. Перетворюється на прихований моноліт.

Немає фіча-прапорів і kill-switch. Будь-яка помилка відразу б'є по всіх.

Змішування OLTP/OLAP. Звіти гальмують ставки/гаманець.

Без спостережуваності. Немає чим виміряти SLO і пов'язувати інциденти.

Чек-лист переходу на модульну архітектуру

Стратегія та домени

Визначені bounded contexts, власники і KPI за модулем.
Карта взаємодій: API/події, критичність і SLO.

Контракти та безпека

OpenAPI/AsyncAPI + JSON-Schema; версія і життєвий цикл.
mTLS/HMAC, короткі JWT, RBAC/ABAC на кордонах.

Дані

Розділені OLTP; події - джерело для OLAP.
Idempotency на API/вебхуках, дедуплікація повідомлень.

CI/CD і релізи

Канарка/blue-green, фіча-прапори, автоскейл по модулю.
Контрактні тести в CI; середа з фейк-провайдерами.

Спостережуваність

Логи/метрики/трейси з'traceId'; SLO-дашборди.
Алерти по бізнес-метрикам (VOID, reject, payout lag).

Комплаєнс

WORM-архів грошей/раундів, експорт регуляторної звітності.
KYC/AML/RG як окремий модуль з журналом рішень.

Міні-приклади

Подія'round. settled@v1`:

json
{
"event":"round. settled",  "v":"1",  "roundId":"R-2025-10-17-evo-23",  "gameId":"evo_blackjack_23",  "bets":[{"betId":"b_92f","playerId":"p_1","stake":"10. 00","payout":"15. 00","outcome":"WIN"}],  "ts":"2025-10-17T14:23:13. 120Z",  "traceId":"tr_5f1"
}

Ідемпотентний гаманець:

http
POST /wallet/settle
X-Idempotency-Key: 9a7f-2b1c
{
"roundId":"R-2025-10-17-evo-23",  "operations":[{"playerId":"p_1","delta":"5. 00","currency":"EUR"}]
}

Модульна архітектура перетворює казино-платформу з «крихкого комбайна» в композицію надійних доменів: кожен зі своїми контрактами, даними і SLO. Це прискорює інтеграції і релізи, дає виборче масштабування, спрощує комплаєнс і знижує ризики інцидентів. Почніть з виділення доменних кордонів, контрактів і подій, «вплетіть» безпеку і спостережуваність - і ви отримаєте платформу, яка росте разом з продуктом, а не гальмує його.