Cómo funciona el módulo Live Casino y el streaming de distribuidores

1) Qué es Live Casino en términos de arquitectura

Live Casino es una plataforma de medios en tiempo real en constante funcionamiento + motor de rondas financieras. En la configuración mínima hay:

Estudio: mesa, cámaras, luz, micrófonos, sensores RFID, monitor del distribuidor (prompter).
Video track: encoders, mezcladores, keyer para sobrecostes (apuestas, temporizadores, pistas).
Orquestador de rondas: estado del juego, ventanas de apuestas, cálculo del resultado, publicación de eventos.
Señal de baja latencia: WebRTC (principal) + LL-HLS/DASH (folback).
Integración con la plataforma: monedero/guardabosques (seamless), límites/regulaciones regionales, juego responsable (RG).
Operaciones: horarios de distribuidores, control de calidad, registro/archivo, moderación de chats.

2) Estudio y equipo

Cámaras y sonido: 1080p/60 o 4K/60 (estático/robótico), micrófonos/bisagras lineales, mezclador.

Sensores/reconocimiento:

RFID en fichas/mesa (ruleta/póquer), escáneres Shoe para blackjack, Visión computarizada (CV) para el reconocimiento de tarjetas/bolas, Pedal del distribuidor para el cambio de fases (open/close bets, no more bets).
Reserva: toma de cámaras y codificadores, alimentación ininterrumpida, estante caliente.

3) Ciclo de vida de la ronda

1. `round. open '- abierto por la recepción de apuestas (por ejemplo, 12-18 segundos).

2. `round. close '/' no _ more _ bets '- la recepción de apuestas está cerrada, las apuestas se van a la colina.

3. `round. play '- el distribuidor distribuye/gira, CV/RFID fijan el resultado.

4. `round. nat '- resultado calculado, pagos/cargos.

5. `round. settle 'es la publicación de los resultados a los jugadores y en el lobby, la actualización de la historia.

Invariantes: la ventana de apuestas y el evento 'close' deben sincronizarse estrictamente con el videomarcador (SMPTE timecode/server time) para que no se produzcan «apuestas después del gong».

4) Vídeo y protocolos

WebRTC - p95 retraso 150-500 ms al jugador, canal de datos bidireccional (DataChannel) para señales de apuesta/temporizador.

LL-HLS/DASH: reserva para problemas con WebRTC; segmentos 1-2 c, latencia 2-5 c.

Overlay: los temporizadores de la ventana de apuestas, la selección de las apuestas ganadoras, las pistas - renderizado ya sea en el servidor (compuesto) o como overles HTML en la parte superior del reproductor.

Sincronización: se considera «verdad» la hora del servidor (UTC) que se envía al cliente y se utiliza para la cuenta regresiva y el enlace de eventos.

5) Orquestador de rondas y billetera

Seamless-monedero: el dinero se almacena en el operador, el proveedor accede a la API de la cartera:

`bet. place '→ hold por el importe de la apuesta (idempotente, clave por' requestId ').
`round. nat '→ calcular el resultado; release/settle de la colina y payout en el ledger.
El jugador ve el equilibrio instantáneamente después de settle.

Contratos de eventos (simplificado):

json
//Evento de bus
{
"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) Flujos de datos del jugador

Video: WebRTC/LL-HLS.

Señales: WebSocket/WebRTC DataChannel - temporizadores, estados, tarifas disponibles, confirmaciones.

API: APROX/gRPC: colocación de apuestas, solicitud de saldo, historial, límites.

Telemetría: QoS (RTT, dropped frames), latencia 'bet. accept ', errores.

7) Tiempo de espera y retrasos: SLO de destino

Camino "click apuesta → hold': p95 ≤ 150-250 ms en la región.

`round. close '→ parada de recepción: deadline cualificado en el orquestador + clientela «pestillo».

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

Latencia de vídeo: WebRTC p95 ≤ 500 ms; LL-HLS como folback ≤ 3-5 con.

8) Escala y red de borde

Los grupos edge de WebRTC están más cerca de los jugadores (EU/UK/CA/LA/SEA).

Anycast/DNS para el equilibrio; geo-enrutamiento.

Autoscaling: por carga de señales de apuestas y métricas de QoS (RTT, rebufer).

Escudo de origen (LL-HLS) para protección contra bursts.

9) Calidad y observabilidad (QoS)

T-SLO:

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

SLO Business: CR lobby→game, sesión de retención, redondos abortados, quejas.

Dashboards: TraceId (reproductor → API → billetera → proveedor → webhook), tarjetas QoS por geo/operador de telecomunicaciones.

10) Seguridad y honestidad

mTLS en todos los canales interservicios, HMAC en webhooks.

Anti-replay: 'X-Request-Timestamp/Nonce', ventana ± 300 s.

Idempotencia: 'X-Idempotency-Key' en 'bet. place '/pagos/webhooks.

Honestidad de la ronda: grabación de todas las fuentes (vídeo, eventos CV/RFID, pulsando el distribuidor) en el repositorio inmutable (WORM) para disputas y auditorías.

Anti-cheat: protección contra las apuestas «tardías» en el cliente (UI-prohibición) + servidor deadline como única fuente de verdad.

11) Chat y moderación

Filtración de toxicidad/spam (modelos NLP), ban stop-word.

Ralentización de la frecuencia de los mensajes, anti-flood.

Moderación del distribuidor: paneles de pistas/señales, prohibición de transmisión PII.

Los registros de chat son parte de la auditoría.

12) Accidentes y folbacks

WebRTC caída: folback automático en LL-HLS; las apuestas se limitan temporalmente a una fecha límite anterior.

Fallo CV/RFID: entrada manual del resultado con doble comprobación y referencia de registro; la ronda puede convertirse en VOID por reglas.

El proveedor no está disponible: «mantenimiento» de mesas, cambio de jugadores a mesas adyacentes, compensación.

13) Cumplimiento y RG

Overlay edad/legal por país/local.

RG-nage: ofertas de pausa/límites con patrones de riesgo.

KYC/AML/KYT: el acceso a mesas/límites de apuestas están relacionados con el estado de KYC y la detección de pagos/direcciones.

Geo-blocking: IP/GPS/documento autorizado por los proveedores de jurisdicción.

14) Ejemplos de API (simplificado)

Colocación de la apuesta (idempotente):

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

Respuesta:

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

Evento de cierre de recepción de apuestas:

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

15) Integración con proveedores de juegos

La capa de puente normaliza las diferencias: identificadores, límites, side-bets, estados.

Contratos: formato único 'roundId/betId', tarjetas de error.

Modos de billetera: seamless (preferiblemente) o transfer (depósito del proveedor, más fricción).

16) DR/HA para Live

Estudio Multi-AZ o estudio de respaldo; presets sincronizados.

Replicación de señales (orquestador, CV) y grabación en dos repositorios independientes.

Procedimientos VOID/REFUND por paquete de rondas con registro de causas y firmas de los responsables.

17) Anti-patrones

Considerar la hora del cliente como «verdad» → apuestas/disputas tardías.

Mezclar OLTP (monedero) y análisis de streaming → aumento de latencia y 'reject _ rate'.

No hay idempotencia → adeudos dobles en los retratos de la red.

La ausencia de folback LL-HLS → una «pantalla negra» cuando WebRTC se degradó.

Actualizar UI/assets sin versionar → overlays «rotos».

Ignorar la moderación de los chats → toxicidad y quejas, riesgo para la licencia.

18) Lista de comprobación de inicio de escritorio Live Casino

Estudio

Duplicación de cámaras/codificadores, control de luz/ruido, UPS.
Los RFID/CV están calibrados, el pedal del distribuidor funciona.

Protocolos y sincronización

Hora del servidor → cliente, deduplines exactos 'round. close`.
WebRTC p95 ≤ 500 ms, LL-HLS se configura como folback.

Finanzas

Seamless-monedero, idempotencia 'bet. place/settle`.
PITR y el registro de rondas en WORM.

Observabilidad

Dashboards QoS, 'bet. reject_rate', 'settle p95', alertas VOID/aborto.
Los registros de chat y acción del distribuidor, de extremo a extremo 'traceId'.

Seguridad/Cumplimiento

mTLS/HMAC, anti-replay, tokenización PII.
RG-overlays y políticas de local, geo-blocking por jurisdicción.

Operaciones

Incidentes de Runbooks, escenarios VOID/REFUND, estudio de respaldo.
Plan de lanzamientos de UI/overlay sin downtime (manifiestos CDN).

El módulo Live Casino es una fusión de vídeo en tiempo real, estricta lógica financiera y disciplina operativa. El éxito está determinado por la sincronización de los deadline con el vídeo, la cartera fiable, la baja latencia (WebRTC con LL-HLS-folback), la observabilidad de QoS y el cumplimiento. Con estos principios, el jugador ve un juego vivo, honesto e impecablemente estable - y la plataforma obtiene márgenes predecibles y escalabilidad.