Інтеграція 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→platforma

'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 Коллбеки platforma→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-казино і шоу-формати масштабуються передбачувано, витримують пікові ефіри і залишаються прозорими для гравця, бренду і регулятора.