Comment fonctionne le module Live Casino et le streaming des revendeurs

1) Qu'est-ce que Live Casino en termes d'architecture

Live Casino est une plateforme multimédia en temps réel en continu + un moteur de round financier. Dans la configuration minimale, il y a :

Studio : table, caméras, lumière, microphones, RFID/capteurs, moniteur de revendeur (prompter).
Vidéo : encodeurs, mixeurs, keyer pour les overleys (paris, minuteries, indices).
Orchestrateur de tours : état du jeu, fenêtres de paris, calcul de l'issue, publication des événements.
Signal à faible retard : WebRTC (principal) + LL-HLS/DASH (folback).
Intégration avec la plate-forme : portefeuille/ledger (seamless), limites/règles régionales, jeu responsable (RG).
Opérations : horaires des revendeurs, contrôle qualité, enregistrement/archive, modération des chats.

2) Studio et équipement

Caméras et son : 1080p/60 ou 4K/60 (statique/robotique), microphones/boucles linéaires, mixeur.

Capteurs/reconnaissance :

RFID en jetons/table (roulette/poker), scanners Shoe pour blackjack, Vision par ordinateur (CV) pour la reconnaissance des cartes/boules, Pédale de dealer pour le changement de phase (bets ouverts/close, no more bets).
Redondance : prises de caméra et encodeurs, alimentation sans interruption, rack chaud.

3) Cycle de vie de la ronde

1. `round. open '- la réception des paris est ouverte (par exemple, 12-18 secondes).

2. `round. close '/' no _ more _ bets '- l'acceptation des paris est fermée, les paris vont dans la colline.

3. `round. play '- le revendeur distribue/tourne, CV/RFID enregistre le résultat.

4. `round. result '- résultat calculé, paiements/pertes.

5. `round. settle 'est la publication des résultats aux joueurs et au lobby, une mise à jour de l'histoire.

Invariants : la fenêtre de paris et l'événement 'close' doivent être strictement synchronisés avec le marqueur vidéo (SMPTE timecode/server time) afin qu'il n'y ait pas de « paris post-gong ».

4) Vidéo et protocoles

WebRTC - p95 150-500 ms de retard au joueur, un canal de données bidirectionnel (DataChannel) pour les signaux de mise/temporisation.

LL-HLS/DASH - réserve en cas de problèmes avec le WebRTC ; segments 1-2 c, retard 2-5 s.

Overlay : minuteries de la fenêtre de mise, mise en surbrillance des paris gagnants, conseils - rendu soit sur le serveur (composite) ou comme un HTML-overlay au-dessus du lecteur.

Synchronisation : La « vérité » est considérée comme l'heure serveur (UTC) qui est envoyée au client et utilisée pour le compte à rebours et la liaison des événements.

5) Orchestrateur de tours et portefeuille

Portefeuille seamless : l'argent est stocké auprès de l'opérateur, le fournisseur accède à l'API du portefeuille :

`bet. place '→ hold pour le montant du pari (idempotent, clé par' requestId ').
`round. result' → calculer le résultat ; release/settle hold et payout dans le ledger.
Le joueur voit l'équilibre instantanément après settle.

Contrats d'événements (simplifiés) :

json
//Événement dans le pneu
{
"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) Flux de données du joueur

Vidéo : WebRTC/LL-HLS.

Signaux : WebSocket/WebRTC DataChannel - minuteries, statuts, tarifs disponibles, confirmations.

API : REST/gRPC - placement du pari, demande de solde, historique, limites.

Télémétrie : QoS (RTT, frames droppées), latence 'bet. accept', erreurs.

7) Temporisation et retards : SLO ciblé

Le chemin du « clic du pari → hold » : p95 ≤ 150-250 ms dans la région.

`round. close '→ stop de réception : debline qualifiée dans l'orchestrateur + « loquet » client.

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

Délai vidéo : WebRTC p95 ≤ 500 ms ; LL-HLS comme folback ≤ 3-5 s.

8) Mise à l'échelle et réseau de bord

Les pools WebRTC Edge sont plus proches des joueurs (EU/UK/CA/LA/SEA).

Anycast/DNS pour équilibrer ; géo-routage.

Autoscaling : en fonction de la charge des signaux de mise et des métriques QoS (RTT, rebuffer).

Bouclier d'origine (LL-HLS) pour la protection contre les bourgeons.

9) Qualité et observabilité (QoS)

Tu-SLO :

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

SLO d'affaires : CR lobby→game, séance de retenue, rounds abortés, plaintes.

Dashboards : trajets de bout en bout 'traceId' (lecteur → API → portefeuille → fournisseur → webhook), cartes QoS par géo/opérateurs de télécommunications.

10) Sécurité et honnêteté

mTLS sur tous les canaux interservices, HMAC sur webhooks.

Anti-replay : 'X-Request-Timestamp/Nonce', fenêtre ± 300 s.

Idempotence : 'X-Idempotency-Key' sur 'bet. place '/paiements/webhooks.

Honnêteté de la ronde : enregistrer toutes les sources (vidéo, événements CV/RFID, click dealer) dans un entrepôt immuable (WORM) pour les litiges et les audits.

Anti-cheat : protection contre les paris « tardifs » sur le client (ban UI) + dedline serveur comme seule source de vérité.

11) Chat et modération

Filtration toxicité/spam (modèle NLP), mots stop ban.

Ralentir la fréquence des messages, anti-flood.

Modération du revendeur : panneaux d'indices/signaux, interdiction de transmettre des PII.

Les logs de chat font partie de l'audit.

12) Accidents et folbacks

Chute de WebRTC : folback automatique sur LL-HLS ; les taux sont temporairement limités à la date limite antérieure.

Panne CV/RFID : entrée manuelle du résultat avec double contrôle et référence d'écriture ; la ronde peut devenir VOID selon les règles.

Le fournisseur n'est pas disponible : « maintenance » des tables, changement de joueurs dans les tables voisines, compensation.

13) Conformité et RG

Âge/droit overlay par pays/local.

RG-nage : propositions de pause/limites pour les modèles de risque.

KYC/AML/KYT : l'accès aux tables/les limites tarifaires sont liées au statut KYC et à l'examen des paiements/adresses.

Géo-blocage : IP/GPS/document autorisé par les fournisseurs de juridiction.

14) Exemples d'API (simplifié)

Placement du pari (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/..."}
}

Réponse :

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

Événement de clôture de la réception des paris :

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

15) Intégration avec les fournisseurs de jeux

La couche bridge normalise les différences : identifiants, limites, side-bets, statuts.

Contrats : format unique 'roundId/betId', cartes d'erreur.

Modes portefeuille : seamless (de préférence) ou transfer (dépôt chez le fournisseur, plus de friction).

16) DR/HA pour Live

Studio Multi-AZ ou studio de secours ; presets synchronisés.

Réplication des signaux (orchestrateur, CV) et enregistrement dans deux entrepôts indépendants.

Procédures VOID/REFUND pour un paquet de tours avec un journal des causes et des signatures des responsables.

17) Anti-modèles

Considérer l'heure du client comme « la vérité » → les paris tardifs/différends.

Mélanger OLTP (portefeuille) et analyse en streaming → augmentation de la latence et « reject _ rate ».

Il n'y a pas d'idempotence → de doubles débits dans les retraits du réseau.

L'absence de folback LL-HLS → « écran noir » lors de la dégradation WebRTC.

Mettre à jour les UI/assets sans version → les overleys « battues ».

Ignorer la modération des chats → la toxicité et les plaintes, le risque pour la licence.

18) Chèque de démarrage de la table Live Casino

Studio

Prises de caméras/encodeurs, contrôle de la lumière/du bruit, UPS.
RFID/CV calibrés, la pédale du concessionnaire fonctionne.

Protocoles et synchronisation

L'heure du serveur → le client, les deadlines exactes. close`.
WebRTC p95 ≤ 500 ms, LL-HLS configuré comme folback.

Finances

Portefeuille de seamless, idempotence 'bet. place/settle`.
PITR et journal des rounds dans WORM.

Observabilité

Dashboards QoS, 'bet. reject_rate', « settle p95 », alertes VOID/avortement.
Logs de chat et actions du revendeur, "traceId'de bout en bout.

Sécurité/Conformité

mTLS/HMAC, anti-replay, tokenization PII.
RG-overley et politiciens locaux, géo-blocage par juridiction.

Opérations

Runbooks incidents, scripts VOID/REFUND, studio de secours.
Plan de libération des UI/overleys sans interruption de service (manifeste CDN).

Le module Live Casino est un alliage de vidéos en temps réel, de logique financière rigoureuse et de discipline opérationnelle. Le succès est déterminé par la synchronisation des deadlines avec la vidéo, un portefeuille fiable, une faible latence (WebRTC avec LL-HLS-folback), l'observation de QoS et la conformité. Si ces principes sont respectés, le joueur voit un jeu vivant, honnête et impeccablement stable - et la plate-forme obtient des marges prévisibles et une évolutivité.