Live Dealer Platforms
Introduction
Live casinos with real dealers are one of the key trends in the industry. Platforms must provide high quality video streaming, synchronous bet processing, clear round logic and reliable financial transaction protection. The main components and architectural solutions for launching live dealers are described below.
1. Video streaming: WebRTC vs RTMP
WebRTC
Low latency (≤200 ms), peer-to-peer or via SFU (Media Server).
Used for interactive elements: desktop translation and WebSocket for management.
RTMP → HLS/DASH
Wide compatibility, but high latency (5-10 s).
Suitable for mass presentations, not interactive bets.
Recommendation: SFU solution (Janus, Jitsi, mediasoup) for scaling WebRTC streams via CDN-edge.
2. Live microservices architecture
```mermaid
flowchart LR
subgraph Player
Browser/WebApp
end
subgraph Platform
API-Gateway
AuthService
SessionService
BetService
LiveService
MessageBroker[(Kafka/RabbitMQ)]
end
subgraph Streaming
SFU[mediasoup/SFU]
CDN[Edge CDN]
end
LiveService manages room creation, dealer and player authorization.
SFU (Selective Forwarding Unit) scales the video stream.
BetService handles WebSocket synchronized bids.
3. Session and round management
1. State Machine
Состояния: `waiting`, `betting_open`, `betting_closed`, `result`, `payout`.
Timer transitions (for example, 30 s for accepting bets, 10 s for the result).
2. Synchronism
Each WebSocket client receives' roundId'and start/end timestamps for accepting bets.
BetService checks the timer and confirms or rejects bids.
4. UI/UX for players
Built-in video window: PWA/SPA with 'video' element, custom control 'Bet Panel'.
Overlay indicators: countdown timer, current dealer job, result history.
Adaptive bitrate: automatic selection of quality depending on bandwidth.
5. Scalability and fault tolerance
Auto-scaling SFU clusters: Kubernetes HPA by the number of WebRTC sessions.
Geo-regions: edge-SFU in key regions, minimizing ping.
Failover: backup SFU cluster with redirection through health-checks.
6. Safety and compliance
mTLS between microservices and SFUs for flow authentication.
TLS encryption of WebRTC (DTLS/SRTP) and WebSocket (WSS).
Anti-fraud: limiting the number of bets per user, scoring anomalies (PMF patterns).
KYC/AML: verification before admission to the live table, automatic checks of high-roller rates.
7. Monitoring and analytics
SFU metrics: concurrent streams, packet loss, RTT, jitter.
Bet-metrics: round bets, response time, percentage of successful transactions.
Dashboards: Grafana broken down by table, region, video quality.
Alerting: PagerDuty at packet loss> 5% or p99 latency> 500 ms.
Conclusion
Support for live dealers requires a complex stack: low-latency video via WebRTC and SFU, reliable bet synchronization, fault-tolerant micro-service architecture and tight security measures. The right choice of components and their integration ensures a smooth, interactive experience and scalability for thousands of simultaneous players.
Live casinos with real dealers are one of the key trends in the industry. Platforms must provide high quality video streaming, synchronous bet processing, clear round logic and reliable financial transaction protection. The main components and architectural solutions for launching live dealers are described below.
1. Video streaming: WebRTC vs RTMP
WebRTC
Low latency (≤200 ms), peer-to-peer or via SFU (Media Server).
Used for interactive elements: desktop translation and WebSocket for management.
RTMP → HLS/DASH
Wide compatibility, but high latency (5-10 s).
Suitable for mass presentations, not interactive bets.
Recommendation: SFU solution (Janus, Jitsi, mediasoup) for scaling WebRTC streams via CDN-edge.
2. Live microservices architecture
```mermaid
flowchart LR
subgraph Player
Browser/WebApp
end
subgraph Platform
API-Gateway
AuthService
SessionService
BetService
LiveService
MessageBroker[(Kafka/RabbitMQ)]
end
subgraph Streaming
SFU[mediasoup/SFU]
CDN[Edge CDN]
end
| Browser/WebApp --> | WS/REST | API-Gateway |
|---|---|---|
| API-Gateway --> AuthService | ||
| AuthService --> SessionService | ||
| SessionService --> LiveService | ||
| LiveService --> SFU | ||
| SFU --> | WebRTC | Browser/WebApp |
| LiveService --> MessageBroker | ||
| MessageBroker --> BetService | ||
| BetService --> SessionService | ||
| ``` |
LiveService manages room creation, dealer and player authorization.
SFU (Selective Forwarding Unit) scales the video stream.
BetService handles WebSocket synchronized bids.
3. Session and round management
1. State Machine
Состояния: `waiting`, `betting_open`, `betting_closed`, `result`, `payout`.
Timer transitions (for example, 30 s for accepting bets, 10 s for the result).
2. Synchronism
Each WebSocket client receives' roundId'and start/end timestamps for accepting bets.
BetService checks the timer and confirms or rejects bids.
4. UI/UX for players
Built-in video window: PWA/SPA with 'video' element, custom control 'Bet Panel'.
Overlay indicators: countdown timer, current dealer job, result history.
Adaptive bitrate: automatic selection of quality depending on bandwidth.
5. Scalability and fault tolerance
Auto-scaling SFU clusters: Kubernetes HPA by the number of WebRTC sessions.
Geo-regions: edge-SFU in key regions, minimizing ping.
Failover: backup SFU cluster with redirection through health-checks.
6. Safety and compliance
mTLS between microservices and SFUs for flow authentication.
TLS encryption of WebRTC (DTLS/SRTP) and WebSocket (WSS).
Anti-fraud: limiting the number of bets per user, scoring anomalies (PMF patterns).
KYC/AML: verification before admission to the live table, automatic checks of high-roller rates.
7. Monitoring and analytics
SFU metrics: concurrent streams, packet loss, RTT, jitter.
Bet-metrics: round bets, response time, percentage of successful transactions.
Dashboards: Grafana broken down by table, region, video quality.
Alerting: PagerDuty at packet loss> 5% or p99 latency> 500 ms.
Conclusion
Support for live dealers requires a complex stack: low-latency video via WebRTC and SFU, reliable bet synchronization, fault-tolerant micro-service architecture and tight security measures. The right choice of components and their integration ensures a smooth, interactive experience and scalability for thousands of simultaneous players.
