Torrent Gear

How Live Casino and Dealer Streaming Works

1) What is Live Casino architecturally

Live Casino is an ongoing real-time media platform + financial round engine. The minimum configuration has:

Studio: desk, cameras, lights, microphones, RFID/sensors, dealer monitor (prompter).
Video path: encoders, mixers, keyer for overlays (bets, timers, tips).
Orchestrator of rounds: game status, betting windows, calculation of the outcome, publication of events.
Low delay signal: WebRTC (main) + LL-HLS/DASH (folback).
Integration with the platform: wallet/ledger (seamless), limits/regional rules, Responsible Gaming (RG).
Operations: dealer schedule, quality control, recording/archive, moderation of chats.

2) Studio and equipment

Cameras and sound: 1080p/60 or 4K/60 (static/robotic), line microphones/loops, mixer.

Sensors/recognition:

RFID in chips/table (roulette/poker), Shoe scanners for blackjack, Computer vision (CV) for card/ball recognition, Dealer pedal for phase change (open/close bets, no more bets).
Redundancy: duplicates of cameras and encoders, uninterrupted power supply, hot rack.

3) Round life cycle

1. `round. open '- acceptance of bets is open (for example, 12-18 seconds).

2. `round. close '/' no _ more _ bets' - betting is closed, bets go to hold.

3. `round. play '- the dealer hands out/twists, CV/RFID record the result.

4. `round. result '- the outcome is calculated, payments/write-offs.

5. `round. settle '- publishing results to players and in the lobby, updating history.

Invariants: The betting window and the'close' event must be strictly synchronized with the video marker (SMPTE timecode/server time) so that "after-gong betting" does not occur.

4) Video path and protocols

WebRTC - p95 150-500ms delay to player, bi-directional data channel (DataChannel) for bet/timer signals.

LL-HLS/DASH - reserve for problems with WebRTC; segments 1-2 s, delay 2-5 s.

Overlays: betting window timers, highlighting winning bets, hints - rendered either on the server (composite) or as an HTML overlay on top of the player.

Synchronization: "true" is server time (UTC), which is sent to the client and used to countdown and bind events.

5) Orchestrator rounds and wallet

Seamless wallet: money is stored by the operator, the provider refers to the wallet API:

`bet. place '→ hold on the bet amount (idempotently, key by' requestId ').
`round. result '→ calculate the outcome; release/settle hold and payout in the ledger.
The player sees the balance instantly after the settle.

Event contracts (simplified):

json
//Bus event
{
"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) Player data streams

Video: WebRTC/LL-HLS.

Signals: WebSocket/WebRTC DataChannel - timers, statuses, available bets, confirmations.

API: REST/gRPC - bid placement, balance request, history, limits.

Telemetry: QoS (RTT, dropped frames), latency'bet. accept ', errors.

7) Timing and delays: Target SLOs

Path "click rate → hold": p95 ≤ 150-250 ms in the region.

`round. close '→ stop reception: qualified deadline in the orchestrator + client "latch."

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

Video delay: WebRTC p95 ≤ 500 ms; LL-HLS as a folback ≤ 3-5 s.

8) Scaling and edge network

Edge pools WebRTC closer to players (EU/UK/CA/LA/SEA).

Anycast/DNS for balancing; geo-routing.

Autoscaling: by the load of bet signals and QoS metrics (RTT, rebuffer).

Origin shield (LL-HLS) for protection against bursts.

9) Quality and observability (QoS)

Tech-SLO:

WebRTC RTT, bitrate, dropped frames, packet loss.
`bet. reject_rate` (<0. 2%), 'void/refund' bursts, 'round. settle p95`.
Lags CV/RFID.

Business SLO: CR lobby→game, session hold, aborted rounds, complaints.

Dashboards: end-to-end traceId (player → API → wallet → provider → webhook), QoS cards for geo/telecom operators.

10) Safety and integrity

mTLS on all inter-service channels, HMAC on webhooks.

Anti-replay: 'X-Request-Timestamp/Nonce', window ± 300 sec.

Idempotency: 'X-Idempotency-Key' on 'bet. place '/payments/webhooks.

Round integrity: Record all sources (video, CV/RFID events, dealer clicks) in immutable storage (WORM) for disputes and audits.

Anti-cheat: protection against "late" bets on the client (UI ban) + server deadline as the only source of truth.

11) Chat and moderation

Toxicity/spam filtering (NLP models), stop word ban.

Slow message rate, anti-flood.

Dealer moderation: prompt/signal panels, PII transmission inhibition.

Chat logs are part of the audit.

12) Accidents and fouls

WebRTC drop: automatic folbacking on LL-HLS; rates are temporarily limited to the earlier deadline.

CV/RFID failure: manual entry of the outcome with double check and reference to the record; round can become VOID by rules.

Provider unavailable: "maintenance" tables, switching players to neighboring tables, compensation.

13) Compliance and RG

Age/legal overlays by country/locale.

RG-naj: Pause/limit suggestions for risk patterns.

KYC/AML/KYT: Table access/rate limits are linked to KYC status and payment/address screening.

Geo-blocking: IP/GPS/document, allowed providers by jurisdiction.

14) API examples (simplified)

Bid placement (idempotent):

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/..."}
}

Answer:

json
{"status":"ACCEPTED","betId":"b_92f","balanceAfter":"245. 30","hold":"10. 00"}

Betting closing event:

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

15) Integration with game providers

The bridge layer normalizes differences: identifiers, limits, side-bets, statuses.

Contracts: single 'roundId/betId' format, error maps.

Wallet modes: seamless (preferably) or transfer (deposit from the provider, more friction).

16) DR/HA for Live

Multi-AZ studios or backup studio; synchronized presets.

Signal replication (orchestrator, CV) and writing to two independent stores.

VOID/REFUND procedures for a batch of rounds with a reason log and signatures of those responsible.

17) Anti-patterns

Consider the client's time as "truth" → late bets/disputes.

Mixing OLTP (wallet) and streaming analytics → an increase in latency and 'reject _ rate'.

No idempotency → double debits in network retrays.

The lack of folback LL-HLS → a "black screen" during WebRTC degradation.

Update UI/assets without version → "broken" overlays.

Ignore moderation of chats → toxicity and complaints, risk to license.

18) Live Casino Table Launch Checklist

Studio

Camera/encoder duplicates, light/noise control, UPS.
RFID/CV calibrated, dealer pedal working.

Protocols and synchronization

Server time → client, exact deadlines'round. close`.
WebRTC p95 ≤ 500ms, LL-HLS configured as folback.

Finance

Seamless wallet, idempotency 'bet. place/settle`.
PITR and round log in WORM.

Observability

QoS dashboards, 'bet. reject_rate', 'settle p95', VOID alerts/abortions.
Dealer chat and activity logs, end-to-end 'traceId'.

Safety/Compliance

mTLS/HMAC, anti-replay, PII tokenization.
RG overlays and locale policies, geo-blocking by jurisdiction.

Operations

Runbooks incidents, VOID/REFUND scripts, backup studio.
No downtime UI/overlay release plan (CDN manifests).

The Live Casino module is a fusion of real-time video, rigorous financial logic and operational discipline. Success is determined by synchronization of deadlines with video, a reliable wallet, low latency (WebRTC with LL-HLS-folback), QoS observability and compliance. If these principles are followed, the player sees a lively, honest and impeccably stable game - and the platform gets predictable margins and scalability.