Как работает модуль Live Casino и стриминг дилеров

1) Что такое Live Casino с точки зрения архитектуры

Live Casino — это постоянно работающая медиаплатформа реального времени + финансовый движок раундов. В минимальной конфигурации есть:

Студия: стол, камеры, свет, микрофоны, RFID/датчики, монитор дилера (prompter).
Видеотракт: энкодеры, микшеры, keyer для оверлеев (ставки, таймеры, подсказки).
Оркестратор раундов: статус игры, окна ставок, расчёт исхода, публикация событий.
Сигнал низкой задержки: WebRTC (основной) + LL-HLS/DASH (фолбэк).
Интеграция с платформой: кошелёк/леджер (seamless), лимиты/региональные правила, Responsible Gaming (RG).
Операции: расписание дилеров, контроль качества, запись/архив, модерация чатов.

2) Студия и оборудование

Камеры и звук: 1080p/60 или 4K/60 (статические/роботизированные), линейные микрофоны/петлички, микшер.

Датчики/распознавание:

RFID в фишках/столе (рулетка/покер), Shoe-сканеры для блекджека, Компьютерное зрение (CV) для распознавания карт/шаров, Педаль дилера для смены фаз (open/close bets, no more bets).
Резервирование: дубли камер и энкодеров, бесперебойное питание, горячая стойка.

3) Жизненный цикл раунда

1. `round.open` — открыт приём ставок (например, 12–18 сек).

2. `round.close` / `no_more_bets` — приём ставок закрыт, ставки уходят в холд.

3. `round.play` — дилер раздаёт/крутит, CV/RFID фиксируют результат.

4. `round.result` — исход рассчитан, выплаты/списания.

5. `round.settle` — публикация результатов игрокам и в лобби, обновление истории.

Инварианты: окно ставок и событие `close` должны быть строго синхронизированы с видеомаркером (SMPTE timecode / server time), чтобы не возникало «ставок после гонга».

4) Видеотракт и протоколы

WebRTC — p95 задержка 150–500 мс до игрока, двунаправленный канал данных (DataChannel) для сигналов ставки/таймеров.

LL-HLS/DASH — резерв при проблемах с WebRTC; сегменты 1–2 c, задержка 2–5 с.

Оверлеи: таймеры окна ставок, выделение победных ставок, подсказки — рендерятся либо на сервере (композит), либо как HTML-оверлей поверх плеера.

Синхронизация: «истиной» считается серверное время (UTC), которое отправляется на клиент и используется для обратного отсчёта и привязки событий.

5) Оркестратор раундов и кошелёк

Seamless-кошелёк: деньги хранятся у оператора, провайдер обращается к API кошелька:

`bet.place` → hold на сумму ставки (идемпотентно, ключ по `requestId`).
`round.result` → рассчитать исход; release/settle холда и payout в леджере.
Игрок видит баланс мгновенно после settle.

Контракты событий (упрощённо):

json
// Событие в шину
{
"event":"round.settle",  "gameId":"evo_blackjack_23",  "roundId":"R-2025-10-17T14:23:10Z-evo-23",  "bets":[{"betId":"b_92f","playerId":"p_1","stake":"10.00","payout":"15.00","outcome":"WIN"}],  "calcVer":"wallet-7.2",  "ts":"2025-10-17T14:23:13.120Z",  "traceId":"tr_5f1"
}

6) Потоки данных игрока

Видео: WebRTC/LL-HLS.

Сигналы: WebSocket/WebRTC DataChannel — таймеры, статусы, доступные ставки, подтверждения.

API: REST/gRPC — размещение ставки, запрос баланса, история, лимиты.

Телеметрия: QoS (RTT, dropped frames), латентность `bet.accept`, ошибки.

7) Тайминг и задержки: целевые SLO

Путь «клик ставки → hold»: p95 ≤ 150–250 мс в регионе.

`round.close` → стоп приёма: квалифицированный дедлайн в оркестраторе + клиентская «защелка».

`result → payout`: p95 ≤ 1–2 с.

Видео-задержка: WebRTC p95 ≤ 500 мс; LL-HLS как фолбэк ≤ 3–5 с.

8) Масштабирование и краевая сеть

Edge-пулы WebRTC ближе к игрокам (EU/UK/CA/LA/SEA).

Anycast/DNS для балансировки; гео-маршрутизация.

Autoscaling: по нагрузке сигналов ставок и QoS метрикам (RTT, rebuffer).

Origin shield (LL-HLS) для защита от бурстов.

9) Качество и наблюдаемость (QoS)

Тех-SLO:

WebRTC RTT, bitrate, dropped frames, packet loss.
`bet.reject_rate` (<0.2%), `void/refund` всплески, `round.settle p95`.
Лаги CV/RFID.

Бизнес-SLO: CR lobby→game, удержание сессии, aborted rounds, жалобы.

Дашборды: сквозные трейсы `traceId` (плеер → API → кошелёк → провайдер → вебхук), карты QoS по гео/операторам связи.

10) Безопасность и честность

mTLS на всех межсервисных каналах, HMAC на вебхуках.

Анти-replay: `X-Request-Timestamp/Nonce`, окно ±300 с.

Идемпотентность: `X-Idempotency-Key` на `bet.place`/выплатах/вебхуках.

Честность раунда: запись всех источников (видео, события CV/RFID, нажатия дилера) в неизменяемое хранилище (WORM) для споров и аудита.

Anti-cheat: защита от «поздних» ставок на клиенте (UI-запрет) + серверный дедлайн как единственный источник истины.

11) Чат и модерация

Фильтрация токсичности/спама (NLP-модели), бан стоп-слов.

Замедление частоты сообщений, анти-флуд.

Модерирование дилера: панели подсказок/сигналов, запрет на передачу PII.

Логи чата — часть аудита.

12) Аварии и фолбэки

Падение WebRTC: автоматический фолбэк на LL-HLS; ставки временно ограничиваются более ранним дедлайном.

Отказ CV/RFID: ручной ввод исхода c двойной проверкой и ссылкой на запись; раунд может стать VOID по правилам.

Провайдер недоступен: «maintenance» столов, переключение игроков в соседние столы, компенсации.

13) Комплаенс и RG

Возрастные/юридические оверлеи по стране/локали.

RG-надж: предложения паузы/лимитов при риск-паттернах.

KYC/AML/KYT: доступ к столам/лимиты ставок связаны со статусом KYC и скринингом платежей/адресов.

Гео-блокинг: IP/GPS/документ, разрешённые провайдеры по юрисдикции.

14) Примеры API (упрощённо)

Размещение ставки (идемпотентно):

http
POST /live/bet/place
X-Idempotency-Key: 9a7f-2b1c
Content-Type: application/json

{
"playerId":"p_123",  "gameId":"evo_blackjack_23",  "roundId":"R-2025-10-17T14:23:10Z-evo-23",  "selection":[{"market":"player","amount":"10.00"}],  "currency":"EUR",  "device":{"ip":"203.0.113.5","ua":"Mozilla/..."}
}

Ответ:

json
{"status":"ACCEPTED","betId":"b_92f","balanceAfter":"245.30","hold":"10.00"}

Событие закрытия приёма ставок:

json
{"event":"round.close","roundId":"R-...","ts":"2025-10-17T14:23:12.000Z"}

15) Интеграция с провайдерами игр

Bridge-слой нормализует различия: идентификаторы, лимиты, side-bets, статусы.

Контракты: единый формат `roundId/betId`, карты ошибок.

Режимы кошелька: seamless (предпочтительно) или transfer (депозит у провайдера, больше трения).

16) DR/HA для Live

Multi-AZ студии или резервная студия; синхронизированные пресеты.

Репликация сигналов (оркестратор, CV) и запись в два независимых хранилища.

Процедуры VOID/REFUND на пачку раундов с журналом причин и подписями ответственных.

17) Анти-паттерны

Считать время клиента «истиной» → поздние ставки/споры.

Смешивать OLTP (кошелёк) и потоковую аналитику → рост латентности и `reject_rate`.

Нет идемпотентности → двойные дебеты при ретраях сети.

Отсутствие фолбэка LL-HLS → «чёрный экран» при деградации WebRTC.

Обновлять UI/ассеты без версияции → «битые» оверлеи.

Игнорировать модерацию чатов → токсичность и жалобы, риск для лицензии.

18) Чек-лист запуска стола Live Casino

Студия

Дубли камер/энкодеров, свет/шумовой контроль, UPS.
RFID/CV калиброваны, педаль дилера работает.

Протоколы и синхронизация

Серверное время → клиент, точные дедлайны `round.close`.
WebRTC p95 ≤ 500 мс, LL-HLS настроен как фолбэк.

Финансы

Seamless-кошелёк, идемпотентность `bet.place/settle`.
PITR и журнал раундов в WORM.

Наблюдаемость

Дашборды QoS, `bet.reject_rate`, `settle p95`, алёрты VOID/аборты.
Логи чата и действий дилера, сквозной `traceId`.

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

mTLS/HMAC, anti-replay, токенизация PII.
RG-оверлеи и политики по локали, гео-блокинг по юрисдикции.

Операции

Runbooks инцидентов, сценарии VOID/REFUND, резервная студия.
План релизов UI/оверлеев без простоя (CDN-манифесты).

Модуль Live Casino — это сплав видео в реальном времени, строгой финансовой логики и операционной дисциплины. Успех определяется синхронизацией дедлайнов с видео, надёжным кошельком, низкой задержкой (WebRTC с LL-HLS-фолбэком), наблюдаемостью QoS и комплаенсом. При соблюдении этих принципов игрок видит живую, честную и безупречно стабильную игру — а платформа получает предсказуемую маржу и масштабируемость.