Як працює модуль 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: ручне введення результату з подвійною перевіркою і посиланням на запис; раунд може стати 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 і комплаєнсом. При дотриманні цих принципів гравець бачить живу, чесну і бездоганно стабільну гру - а платформа отримує передбачувану маржу і масштабованість.