Як влаштована архітектура backend казино

1) Картина цілком: домени і потоки даних

Ключові домени:

Identity & Accounts - реєстрація, автентифікація, ролі, пристрої, сесії.
Wallet & Ledger - грошові рахунки, бонусні гаманці, транзакції, леджер (append-only).
Gaming & Bets - сесії ігор, ставки, раунди, розрахунок результатів, інтеграції (RNG/Live/Crash тощо).
Bonuses & Promotions - фриспіни, кешбек, ваучери, wagering (відіграш), анти-аб'юз.
Payments (Cashier) - он-рамп/офф-рамп: карти, APM, крипта/стейблкоіни, KYC-прив'язка.
KYC/AML/KYT & RG - верифікація особистості/адреси/доходів, скринінг транзакцій, ліміти і тайм-аути.
Risk & Compliance - ліміти ставок/виплат, санкційні списки, гео-блокінг, аудит.
Catalog & Lobby - список провайдерів, ігор, категорій, лімітів; A/B-варіанти.
Reporting & BI - P&L, GGR/NGR, утримання, життєвий цикл гравця, афіліати.
Observability & Ops - логи, метрики, трасування, алерти, фрод-сигнали.

Оркестрація: сучасна платформа будується event-driven: сервіси обміняються подіями через шину (Kafka/NATS), критичні операції лінеаризуються (гаманець/леджер), бічні підсистеми підписуються і реагують асинхронно (бонуси, BI, повідомлення).

2) Шарувата модель

Edge шар: API-шлюз, WAF/бот-захист, rate limits, geo/IP-фільтри, feature-прапори.

Сервісний шар: автономні мікросервіси по доменах; синхронні контракти - тільки там, де потрібна миттєва консистентність (наприклад, дебет гаманця при ставці).

Шина подій: основні бізнес-події ('bet. placed`, `round. settled`, `bonus. issued`, `kyc. verified`, `payout. requested`).

Дані: OLTP (Postgres/MySQL) для транзакцій; KV/Cache (Redis) для сесій/лімітів; об'єктне сховище (S3) для логів та експорту; OLAP (ClickHouse/BigQuery) для аналітики.

3) Гаманець і леджер: серце платформи

Принципи:

Append-only леджер: кожна фінансова операція - запис з типом, сумою, валютою, посиланням на джерело (ставка, бонус, депозит).
Грошові та бонусні баланси рознесені. Не можна «змішувати» гроші і бонуси; використовується політика джерел коштів.
Атомарність debet→kredit: ставка = дебет грошового або бонусного гаманця + створення hold; розрахунок раунду знімає hold і робить кредит/дебет за результатом.

Приклад транзакцій при ставці:

`LEDGER: HOLD` (−10. 00 EUR, source: cash, ref: betId)
`LEDGER: SETTLE_DEBIT` (−10. 00 EUR) + `LEDGER: PAYOUT` (+36. 00 EUR) - якщо WIN
`LEDGER: HOLD_RELEASE` (+10. 00 EUR) - якщо VOID/PUSH

Вимоги:

Ідемпотентні операції (ключі ідемпотентності по'requestId').
Версіонування балансу (optimistic locking) для захисту від гонок.
Чітка валюта розрахунку і фіксування курсів при конверсіях.

4) Інтеграції з провайдерами ігор

Патерни гаманця:

Seamless - баланс у оператора; ставка/розрахунок йдуть через наш API в реальному часі.
Transfer - депозит в банк гри у провайдера; більше тертя, але нижче вимога до аптайму гаманця.

Синхронні шляхи (критичні):

`bet. place'→ pre-auth в гаманці (hold) →'accepted/rejected'.

Асинхронні шляхи:

`round. settle'від провайдера (webhook/WS) → settle в леджері → подія в шину → звітність/бонуси.

Стандартизація через bridge: єдині схеми подій та ідентифікатори'roundId/betId', таблиця маппінгу лімітів і side-bets, нормалізація помилок.

5) Бонуси, wagering і анти-аб'юз

Моделі: депозитні бонуси, фріспіни, повернення (cashback), місії, турніри.

Wagering: прогрес відіграшу зберігається окремо; правило «які ставки рахуються» (відсотки за категоріями ігор).

Черговість списання: спочатку бонусні кошти, потім реальні - або навпаки, строго по політиці.

Анти-патерни гравця: ставки на протилежні результати, мінімальні ставки для фарму прогресу, перенесення між іграми з різними вагами - ловляться правилами і скорингом.

6) KYC/AML/KYT и Responsible Gaming (RG)

KYC: верифікація ID/адреси/віку; статуси керують лімітами (deposit/withdraw/betMax).

AML/KYT: скринінг платіжних каналів і on-chain адрес (для крипти), санкційні списки, джерела коштів.

RG: денні/тижневі ліміти, тайм-аути, самовиключення; блокуючі перевірки виконуються до'bet. place` и `payout. request`.

7) Каса: депозити та виплати

Депозити: провайдери карт/АРМ, крипта/стейбли, локальні методи; webhook-підтвердження; захист від чарджбек-ризиків.

Виплати: черги, ліміти, 4-очний принцип для великих сум; джерела коштів → «тільки cash-баланс».

Он-рамп/офф-рамп крипти: авто-конвертація, KYT адрес, хеджування експозиції.

8) Ліміти, ризик і регіональні правила

Профілі лімітів ('DEFAULT','VIP _ A','VIP _ B','ULTRA') по країні/валюті/КУС.

Гео-блокінг за IP/GPS/документом.

Перекриття за іграми/категоріями, заборони провайдерів у юрисдикціях.

Реакція на аномалії: сплески ставок, кореляція пристроїв/платежів, багато «VOID» від одного користувача.

9) Спостережуваність і експлуатація

Метрики: затримки гаманця, відмова ставок, час розрахунку раунду, конверсія depozita→stavka, GGR/NGR, виплата SLA, частка бонусних ставок.

Логи і трасування: кореляційні'traceId'у всіх подіях; зберігання сирих подій в «холодному» сховищі.

Алерти: деградація відповіді гаманця, сплеск'VOID', помилка reconcile звітів, зростання'RG _ BLOCKED'.

Runbooks: чіткі процедури інцидентів (падіння провайдера, розсинхрон леджера, скасування раундів).

10) Безпека і приватність

Auth: short-lived JWT/opaque tokens, ротація ключів ('kid'), mTLS до критичних інтеграцій.

Політики доступу: суворе розділення ролей (операції, фінанси, саппорт), 2FA; для великих виплат - окей від другої особи.

Data privacy: шифрування PII, токенізація платіжних даних, мінімізація зберігання; GDPR/видалення за запитом.

Аудит: незмінні журнали, підпис критичних подій, експорт для регулятора.

11) Масштабування і відмовостійкість

Стейтлес-сервіси за авто-скейлером; горизонтальний шард для гарячих таблиць (ставки, логи подій).

Леджер - вертикальний запас + реплікації для читання/звітності; «заморожування» схем міграцій через shadow tables.

Кешування: Redis з TTL і «двочековими» стратегіями (read-through + invalidate за подіями).

DR/HA: multi-AZ, бекапи з регулярним відновленням, RPO/RTO на рівні регуляторних вимог.

Degradation режими: автономна каса, відключення «важких» бонусів, переклад live-ігор в maintenance при недоступності шини.

12) Контракти та приклади

Ставка (sync, JSON/REST або gRPC):

json
POST /bets/place
{
"requestId": "9a7f-…",  "playerId": "p_123",  "wallet": "cash",
"roundId": "R-2025-10-17-19:20:05-PRAGM-Table12",  "gameId": "pragm_live_roulette",  "selection": [{"market":"straight","value":"17"}],  "stake": {"amount":"10. 00","currency":"EUR"},  "device": {"ip":"203. 0. 113. 5","ua":"Mozilla/..."}
}

Відповідь:

json
{
"status": "ACCEPTED",  "betId": "bet_8cd…",  "balanceAfter": "245. 30",  "hold": "10. 00",  "limits": {"maxBet":"5000. 00"}
}

Подія в шину (async):

json
{
"event":"round. settled",  "roundId":"R-2025-10-17-19:20:05-PRAGM-Table12",  "bets":[{"betId":"bet_8cd…","outcome":"WIN","stake":"10. 00","payout":"360. 00"}],  "playerId":"p_123",  "ts":"2025-10-17T19:20:09. 231Z",  "traceId":"tr_5f1…"
}

13) Анти-патерни (що ламає платформу)

Змішування бонусних і грошових коштів в одній транзакції без джерел.

Довгоживучі токени і зберігання їх на клієнті.

Відсутність ідемпотентності в критичних операціях (дублі дебету).

Монолітний звітний SQL по бойовій БД (OLAP проти OLTP).

Сліпа довіреність провайдеру без reconcile і лімітів.

Немає таймзон-стандарту (UTC скрізь!) в ідентифікаторах раундів і звітах.

Синхронні виклики в нефінансових доменах (бонуси/повідомлення) блокують ставку.

14) Чек-лист запуску backend казино

Фінанси та гаманець

Леджер append-only, ідемпотентність, версія балансу.
Розділення cash/bonus, політика джерел.
Курси/конверсія фіксуються при операції.

Інтеграції ігор

Єдиний контракт ставок/розрахунку, формат'roundId/betId'.
Seamless-гаманець за замовчуванням; Transfer - тільки де виправдано.
Автоматичний VOID/REFUND сценарії.

KYC/AML/RG

Політики до допуску до ставки/виплати; статуси KYC ↔ ліміти.
KYT для on-chain, санкційний скринінг, зберігання доказової бази.

Каса

Вебхуки/підписи, дублі/ретраї, reconcile з PSP/крипто-провайдерами.
4-eyes на великі виплати, журнал дій операторів.

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

Метрики гаманця, round-settle latency, відмова ставок, SLA виплат.

Трасування наскрізні (traceId), алерти, runbooks.

Безпека

mTLS/HMAC, JWT з коротким TTL, ротація ключів.
Ролі/права, 2FA, токенізація платіжних даних.

Дані

Поділ OLTP/OLAP, CDC в DWH, S3 для сирих подій.
Бекапи і регулярні тести відновлення.

15) Підсумок

Архітектура backend казино - це суворе ядро грошей і ставок з лінеарною консистентністю і гнучка периферія на подіях: бонуси, аналітика, комунікації. Успіх визначається не кількістю мікросервісів, а дисципліною: чіткі доменні межі, леджер без «магії», ідемпотентність, спостережуваність і комплаєнс за замовчуванням. З такою основою платформа масштабується по країнах/валютах/провайдерах і витримує навантаження без компромісів з безпеки і грошей.