Как устроена архитектура 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 леджер: каждая финансовая операция — запись с типом, суммой, валютой, ссылкой на источник (ставка, бонус, депозит).
- Денежные и бонусные балансы разнесены. Нельзя «смешивать» деньги и бонусы; используется политика источников средств.
- Атомарность дебет→кредит: ставка = дебет денежного или бонусного кошелька + создание 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) Касса: депозиты и выплаты
Депозиты: провайдеры карт/APM, крипта/стейблы, локальные методы; webhook-подтверждения; защита от чарджбек-рисков.
Выплаты: очереди, лимиты, 4-глазный принцип для крупных сумм; источники средств → «только cash-баланс».
Он-рамп/офф-рамп крипты: авто-конвертация, KYT адресов, хеджирование экспозиции.
8) Лимиты, риск и региональные правила
Профили лимитов (`DEFAULT`, `VIP_A`, `VIP_B`, `ULTRA`) по стране/валюте/KYC.
Гео-блокинг по IP/GPS/документу.
Перекрытия по играм/категориям, запреты провайдеров в юрисдикциях.
Реакция на аномалии: всплески ставок, корреляция устройств/платежей, много «VOID» от одного пользователя.
9) Наблюдаемость и эксплуатация
Метрики: задержки кошелька, отказ ставок, время рассчёта раунда, конверсия депозита→ставка, 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 казино — это строгое ядро денег и ставок с линеарной консистентностью и гибкая периферия на событиях: бонусы, аналитика, коммуникации. Успех определяется не количеством микросервисов, а дисциплиной: чёткие доменные границы, леджер без «магии», идемпотентность, наблюдаемость и комплаенс по умолчанию. С такой основой платформа масштабируется по странам/валютам/провайдерам и выдерживает нагрузки без компромиссов по безопасности и деньгам.