Интеграция live-игр и шоу-форматов через RGS/bridge

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

💡 18+. Технический материал для команд операторов, студий и агрегаторов. Не призыв к игре. Термины: платформа — PAM/кошелёк/касса/бонусы/RG; RGS — Remote Game Server (ядро игр студии); bridge — интеграционный слой между live-ядром провайдера и платформой/агрегатором.

1) Зачем нужен bridge между live и платформой

Live-игры (рулетка, блэкджек, баккара) и шоу-форматы (Crazy-/Wheel-/Dice-/Game Show) используют видеострим + реальный исход. В отличие от RNG-слотов:

Исход приходит после закрытия окна ставок и физического события (спин, вскрытие карт).
Требуются строгие временные рамки (cut-off) и синхронные локи ставок.
Расчёт выплат идёт по таблицам live-игры, не по матем ядру слота.
Нужно согласовать кошелёк, бонусы, турниры, джекпоты, RG/AML, а также telemetry/отчётность.

Bridge — это S2S-шлюз, который «переводит» живую механику в контракт платформы: токены сессий, авторизация и лимиты, приём ставок, фиксация окна, сеттлмент, компенсации, события и дашборды.

2) Базовая архитектура интеграции


Player Client (Web/Mobile + HLS/WebRTC)
│

Live Provider Front (video, UI) —— Live Engine (round control, GCU)
│                │
│ (S2S)            │ emits outcomes

Bridge (RGS/bridge): auth, bet capture, lock, settle, rollback, jackpots/promos
│

Platform: PAM / Wallet(Ledger) / Cashier / Bonus / RG / Risk / BI
│

Aggregator (optional)

Роли:

Live Engine: управляет раундом, таймерами, исходами (dealer/GCU).
Bridge: единственный интеграционный контур к платформе. Синхронизирует деньги и события.
Платформа: источник истины по балансу, бонусам, RG/AML, отчётности.

3) Потоки и тайминг: от ставки до выплаты

3.1 Жизненный цикл раунда (упрощённо)

1. session.create — проверка бренда/гео/возраста, выдача session_token.

2. bet.place — в окне приёма ставок; проверка RG-лимитов, бонусных правил, идемпотентность (`Idempotency-Key`).

3. bet.lock — закрытие окна (cut-off). Все незафиксированные заявки — отклоняются.

4. live.outcome — исход от Live Engine (рулетка: число; шоу: сектор/множитель/бонус-раунд).

5. bet.settle — атомарный сеттлмент: дебет ставки подтверждён, кредит выигрыша (через кошелёк).

6. bonus/jackpot/tournament — вклад/триггеры.

7. rollback/compensation — при сбое канала, но только по регламенту раунда.

3.2 Окна и задержки

Target latency (glass-to-glass): HLS 2–5 c сегмент; WebRTC 200–500 мс.

SLO bridge:

p95 `bet.place`/`bet.lock` < 150 мс (без сети игрока), p95 `settle` < 300 мс после `live.outcome`, «потерянных/дублированных сеттлментов» = 0.

4) Контракты API bridge ↔ платформа (пример)

4.1 Запросы bridge→платформа

`POST /wallet/debit` — авторизация ставки (идемпотентно, ответ — hold_id).

`POST /wallet/commit` — подтверждение списания при lock.

`POST /wallet/credit` — кредит выигрыша.

`POST /rg/check` — лимиты депозита/потерь/времени, самоисключение.

`POST /bonus/apply` — вклад по типу игры (e.g., live 10–25%).

`POST /jackpot/contribute	trigger` — доля ставки/выигрыш.
`POST /analytics/event` — телеметрия (round, table, latency, error).

4.2 Коллбеки платформа→bridge

`wallet.debit.authorized	rejected`
`wallet.commit.ok	failed`
`wallet.credit.ok	failed`
`rg.blocked` / `rg.limit.hit`
`bonus.state.updated`
`compensation.required` (по протоколу раунда)

Идемпотентность: ключи `round_id`, `bet_id`, `settle_id`; дедуп на стороне кошелька и bridge.

5) Событийная модель (Kafka/Pulsar)

Базовые топики

`live.session.started	ended`
`live.bet.placed	locked
`live.round.outcome`
`live.bet.settled`
`wallet.debit.requested	committed
`bonus.contributed	awarded`, `jackpot.contribution
`rg.limit.hit`, `rg.reality_check`
`risk.alert.raised`

Контракты: Avro/JSON Schema + Registry, семантические версии, партиционирование по `tenant_id`, `table_id`, `player_id`.

6) Денежные инварианты и саги

Истина по балансу — Ledger платформы; bridge хранит состояния ставок/раундов.

Все денежные операции — идемпотентны, с `Idempotency-Key`.

Сага «authorize → lock/commit → settle → credit»:

при фейле `commit` — отмена авторизации/возврат hold;
при фейле `credit` — повтор до успеха;
ручные правки балансов — запрещены; только компенсирующие события.

7) Бонусы, турниры, джекпоты в live

Вклад в вейджер: live-игры обычно дают 10–25% веса; bridge обязан явно передавать тип стола/игры.

Турниры/рейсы: очки за оборот, множители, streaks; источник — события `live.bet.settled`.

Джекпоты: фикс/прогрессив (локальные/сетевые). Взнос с каждой квалифицированной ставкой; триггер — на стороне bridge/джекпот-сервиса.

Ответственность: промо-механики не должны менять шансы основной игры; иначе — отдельная сертификация.

8) Антифрод и риск

Velocity/арбитраж задержек: запрет ставок «после факта»; жёсткий cut-off.

Мульти-аккаунт/общие устройства: графовые проверки, device-fingerprinting.

Аномалии выигрышей: сверх-ожидаемые паттерны по столу/игроку/региону.

Chargeback defense: связка ставок с депозитами/мерчантами, логи hold/commit.

9) Observability и телеметрия

Бизнес-метрики

`bets_per_round`, `players_on_table`, `avg_bet`, `payout_ratio`, `rake`, `jackpot_latency`, `settle_lag_ms`.

Техметрики

p50/p95/p99 по `bet.place`, `bet.lock`, `settle`, `wallet.debit/commit/credit`;

depth очередей, consumer lag, CPU/mem/GC, TLS errors, WebRTC/HLS QoE (stall ratio).

Дашборды

NOC: столы/шоу, онлайн, bets/min, settle lag, error heatmap по регионам.

SRE: latency per endpoint, queue lag, retrу storms, success of commit/credit.

Алерты (SLO-бюджет): p95 `settle` > X, error rate > Y%, lag > Z сек, рост `cancelled` у конкретного стола.

WORM-аудит: изменения лимитов, RTP-профилей шоу-раундов, параметров джекпотов, фич-флагов.

10) Безопасность и комплаенс

mTLS + подписи (HMAC/EdDSA) на всех S2S-вызовах; короткоживущие токены.

Zero-trust: mesh-политики, минимальные привилегии, сегментация по регионам.

PCI/GDPR/Data residency: PII и логи — в регионе (EU/UK/BR…), кросс-чтения запрещены.

RG: синхронные стоп-сигналы на ставке (лимиты депозитов/потерь/времени, самоисключение), reality-check.

Аудит: логи крит-действий — неизменяемые (WORM), доступы «четыре глаза».

11) Мультитенантность и мультибренд

Все события и вызовы помечены `tenant_id/brand_id/license/region`.

Ledger/Cashier/PII — изолированы per лицензия/регион (часто отдельные БД/кластеры).

Общие сервисы (bridge-ядро, турниры, джекпоты) — shareable, но с жёсткой RLS в данных.

Фича-флаги/лимиты/бонус-пулы — на уровне бренда/юрисдикции.

12) Производительность и деградации

Back-pressure: при перегрузке — `no new bets` перед cut-off, приоритизация commit/settle.

Degrade modes: отключение побочных промо/джекпотов, сохранение core-ставок и выплат.

DR-план: актив-актив/актив-пассив; RPO ≤ 5 мин, RTO ≤ 30 мин; синхронизация outbox.

13) Чек-лист внедрения (оператор/провайдер)

Архитектура

Контракты событий (Schema Registry), ключи идемпотентности `round_id/bet_id/settle_id`.
Саги authorize→commit→settle→credit; компенсации без ручных правок.
Outbox/CDC на все денежные состояния; публикаций «в обход» нет.
Cut-off/lock реализованы на стороне live-ядра и защищены сетевыми задержками.

Деньги/бонусы

Ledger как источник истины; hold/commit/credit атомарны.
Вклад live в вейджер прозрачен; турниры/джекпоты не меняют шансы основной игры.

Observability/SLO

Дашборды NOC/SRE; SLO-алерты на latency/error/lag.
WORM-аудит лимитов и фич-флагов; постмортем-процесс.

Безопасность/комплаенс

mTLS + подписи; Vault/HSM; RBAC/ABAC; data residency.
RG-стопы синхронны; AML-сигналы и отчётность автоматизированы.

14) Красные флаги (анти-паттерны)

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

Приём ставок после истечения окна (нет строгого lock).

Публикация телеметрии без outbox/CDC → «теряются» раунды.

Отсутствие идемпотентности и дедупа → дубли выплат.

Смешение PII и денежного контура разных регионов/брендов.

Нет деградаций: падение промо валит расчёт выигрышей.

BI/регуляторные отчёты работают с боевой OLTP.

15) Итог

Bridge для live-игр — это не просто «адаптер API», а денежно-событийное ядро, которое связывает живой исход со строгими инвариантами платформы: кошелёк, бонусы, RG/AML и отчётность. Его сила — в идемпотентности и сагах, жёстких окнах и локах, наблюдаемости и безопасности «по умолчанию». На таком фундаменте live-казино и шоу-форматы масштабируются предсказуемо, выдерживают пиковые эфиры и остаются прозрачными для игрока, бренда и регулятора.