Integration of live games and show formats via RGS/bridge

Full article

💡 18+. Technical material for operator teams, studios and aggregators. Not a call to play. Terms: platform - PAM/wallet/cash desk/bonuses/RG; RGS - Remote Game Server (core of studio games); bridge - the integration layer between the provider's live core and the platform/aggregator.

1) Why do you need a bridge between live and platform

Live games (roulette, blackjack, baccarat) and show formats (Crazy-/Wheel-/Dice-/Game Show) use video stream + real outcome. Unlike RNG slots:

The outcome comes after closing the betting window and a physical event (spin, showdown).
Strict cut-off and synchronous lock bets are required.
The calculation of payments is based on the tables of the live game, not on the math core of the slot.
You need to agree on a wallet, bonuses, tournaments, jackpots, RG/AML, as well as telemetry/reporting.

Bridge is an S2S gateway that "translates" live mechanics into a platform contract: session tokens, authorization and limits, acceptance of bets, window fixation, settlement, compensation, events and dashboards.

2) Basic integration architecture


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)

Roles:

Live Engine: controls round, timers, outcomes (dealer/GCU).
Bridge is the only integration loop to the platform. Synchronizes money and events.
Platform: source of truth in balance, bonuses, RG/AML, reporting.

3) Flows and timing: from bet to pay

3. 1 Round life cycle (simplified)

1. session. create - brand/geo/age verification, session_token issuance.

2. bet. place - in the window for accepting bets; checking RG limits, bonus rules, idempotency ('Idempotency-Key').

3. bet. lock-Close the window (cut-off). All uncommitted applications are rejected.

4. live. outcome - outcome from Live Engine (roulette: number; show: sector/multiplier/bonus round).

5. bet. settle - atomic settlement: bet debit confirmed, win credit (through wallet).

6. bonus/jackpot/tournament - contribution/triggers.

7. rollback/compensation - if the channel fails, but only according to the round regulations.

3. 2 Windows and delays

Target latency (glass-to-glass): HLS 2-5 c segment; WebRTC 200-500 ms.

SLO bridge:

p95 `bet. place`/`bet. lock '<150 ms (no player network), p95' settle '<300 ms after' live. outcome ', "lost/duplicated settlements" = 0.

4) API bridge contracts ↔ platform (example)

4. 1 Requests for bridge→platforma

'POST/wallet/debit '- authorization of the bet (idempotent, the answer is hold_id).

'POST/wallet/commit '- confirmation of write-off when lock.

'POST/wallet/credit '- win credit.

'POST/rg/check '- deposit/loss/time limits, self-exclusion.

'POST/bonus/apply '- contribution by game type (e. g., live 10–25%).

`POST /jackpot/contribute	trigger '- bet share/win.
'POST/analytics/event '- telemetry (round, table, latency, error).

4. 2 Collbacks platforma→bridge

`wallet. debit. authorized	rejected`
`wallet. commit. ok	failed`
`wallet. credit. ok	failed`
`rg. blocked` / `rg. limit. hit`
`bonus. state. updated`
`compensation. required '(per round protocol)

Idempotence: keys' round _ id ',' bet _ id ',' settle _ id '; dedup on the side of the wallet and bridge.

5) Event model (Kafka/Pulsar)

Basic topics

`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`

Contracts: Avro/JSON Schema + Registry, semantic versions, partitioning by 'tenant _ id', 'table _ id', 'player _ id'.

6) Money invariants and sagas

True by balance - Ledger platform; bridge stores betting/round states.

All monetary transactions are idempotent, with'Idempotency-Key '.

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

with file 'commit' - revocation of authorization/return hold;
with the'credit' fail - repeat to success;
manual balance adjustments are prohibited; only compensating events.

7) Bonuses, tournaments, jackpots in live

Contribution to the wager: live games usually give 10-25% weight; bridge is obliged to explicitly convey the type of table/game.

Tournaments/flights: points per turnover, multipliers, streaks; source - live events. bet. settled`.

Jackpots: fix/progressive (local/online). Contribution with each qualified rate; trigger - on the bridge/jackpot side.

Responsibility: Promotional mechanics should not change the chances of the main game; otherwise - separate certification.

8) Antifraud and risk

Velocity/delay arbitration: prohibition of "after fact" bets; hard cut-off.

Multi-account/shared devices: graph checks, device-fingerprinting.

Win anomalies: super-expected patterns by table/player/region.

Chargeback defense: a bunch of bets with deposits/merchants, hold/commit logs.

9) Observability and telemetry

Business metrics

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

Technical metrics

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

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

Dashboards

NOC: tables/shows, online, bets/min, settle lag, error heatmap by region.

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

Alerts (SLO budget): p95 'settle'> X, error rate> Y%, lag> Z sec, growth 'canceled' at a specific table.

WORM audit: changes in limits, RTP profiles of show rounds, jackpot parameters, feature flags.

10) Safety and compliance

mTLS + signatures (HMAC/EdDSA) on all S2S calls short-lived tokens.

Zero-trust: mesh policies, minimum privileges, segmentation by region.

PCI/GDPR/Data residency: PII and logs - in the region (EU/UK/BR...), cross-reads are prohibited.

RG: synchronous stop signals at the rate (limits of deposits/losses/time, self-exclusion), reality-check.

Audit: logs of crete actions - unchangeable (WORM), access "four eyes."

11) Multi-tenancy and multi-brand

All events and calls are marked 'tenant _ id/brand _ id/license/region'.

Ledger/Cashier/PII - isolated per license/region (often separate databases/clusters).

Common services (bridge core, tournaments, jackpots) - shareable, but with hard RLS in the data.

Feature flags/limits/bonus pools - at the brand/jurisdiction level.

12) Performance and degradation

Back-pressure: when overloaded - 'no new bets' before cut-off, commit/settle prioritization.

Degrade modes: disabling side promos/jackpots, saving core bets and payments.

DR-plan: asset-asset/asset-liability; RPO ≤ 5 min, RTO ≤ 30 min; outbox synchronization.

13) Implementation checklist (operator/provider)

Architecture

Event contracts (Schema Registry), idempotence keys' round _ id/bet _ id/settle _ id '.
Саги authorize→commit→settle→credit; compensation without manual adjustments.
Outbox/CDC on all cash states; there are no "bypass" publications.
Cut-off/lock is implemented on the live kernel side and is protected by network delays.

Money/Bonuses

Ledger as a source of truth; hold/commit/credit are atomic.
Live contribution to the wager is transparent; tournaments/jackpots do not change the chances of the main game.

Observability/SLO

NOC/SRE dashboards; SLO alerts to latency/error/lag.
WORM audit of limits and feature flags; postmortem process.

Security/Compliance

mTLS + signatures; Vault/HSM; RBAC/ABAC; data residency.
RG stops are synchronous; AML signals and reporting are automated.

14) Red flags (anti-patterns)

Manual edits of balances/settlements in the database.

Accepting bets after the window expires (no strict lock).

Publishing telemetry without outbox/CDC → "lost" rounds.

Lack of idempotency and deduplication → duplicate payments.

Mixing PII and money contour of different regions/brands.

No degradation: the fall of the promo brings down the calculation of winnings.

BI/regulatory reports work with combat OLTP.

15) The bottom line

Bridge for live games is not just an "API adapter," but a monetary-event kernel that connects a live outcome with strict platform invariants: wallet, bonuses, RG/AML and reporting. Its strength lies in idempotence and sagas, hard windows and locks, observability and security "by default." On such a foundation, live casinos and show formats scale predictably, withstand peak broadcasts and remain transparent to the player, brand and regulator.