Integrazione dei giochi live e dei formati di spettacolo tramite RGS/bridge

Testo completo dell'articolo

💡 18+. Materiale tecnico per team di operatori, studi e aggregatori. Non una chiamata al gioco. Termini: piattaforma - PAM/portafoglio/cassa/bonus/RG; RGS - Remote Game Server (kernel di giochi dello studio); bridge è un livello di integrazione tra il core live del provider e la piattaforma/aggregatore.

1) Perché è necessario bridge tra il live e la piattaforma

I giochi live (roulette, blackjack, baccara) e i formati di spettacolo (Crazy-/Wheel-/Dice-/Game Show) utilizzano un risultato video + reale. A differenza degli slot RNG:

L'esito arriva dopo la chiusura della finestra delle scommesse e l'evento fisico (spin, autopsie delle carte).
Sono necessari orari rigorosi (cut-off) e lotti di puntata sincroni.
I pagamenti si basano sulle tabelle del gioco live, non sul nucleo matem dello slot.
È necessario concordare portafogli, bonus, tornei, jackpot, RG/AML e anche telemetry/rendicontazione.

Bridge è un gateway S2S che «traduce» la meccanica vivente in un contratto di piattaforma: token sessioni, autorizzazioni e limiti, accettazione di scommesse, fissazione finestra, settlment, compensi, eventi e dashboard.

2) Architettura di base per l'integrazione


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)

Ruoli:

Live Engine controlla round, timer, esiti (dealer/GCU).
Bridge - Unico tracciato di integrazione della piattaforma. Sincronizza i soldi e gli eventi.
La piattaforma è la fonte di verità su bilanci, bonus, RG/AML, rapporti.

3) Flussi e timing: dalla puntata al pagamento

3. 1 Ciclo di vita del round (semplificato)

1. session. create - controllo del marchio/geo/età, rilascio di sessione _ token.

2. bet. place - nella finestra di accettazione delle scommesse Controllo dei limiti RG, delle regole di bonifica, idipotenza ('Idempotency-Key').

3. bet. lock - Chiusura della finestra (cut-off). Tutte le richieste non segnalate vengono rifiutate.

4. live. outcome - esito di Live Engine (roulette: numero; spettacolo: settore/moltiplicatore/bonus round).

5. bet. settle - Settlment atomico - Il debito della puntata è confermato, il prestito della vincita (tramite portafoglio).

6. Bonus/jackpot/tornment - contributo/trigger.

7. rollback/competation - in caso di guasto del canale, ma solo in base al regolamento del round.

3. 2 Finestre e ritardi

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

SLO bridge:

p95 `bet. place`/`bet. lock' <150 mc (senza rete del giocatore), p95 'settle' <300 mc dopo 'live. outcome, «settementi persi/duplicati» = 0.

4) Contratti API bridge piattaforma (esempio)

4. 1 Richieste di bridge→platforma

«POST/wallet/debit» è l'autorizzazione della scommessa (idem, la risposta è hold _ id).

«POST/wallet/commit» conferma il prelievo in lock.

«POST/wallet/credit» è il prestito della vincita.

«POST/rg/check» - limiti di deposito/perdita/tempo, auto-esclusione.

«POST/bonus/apply» è un contributo per tipo di gioco (e. g., live 10–25%).

`POST /jackpot/contribute	trigger - quota di puntata/vincita.
«POST/analytics/event» - telemetria (round, table, latency, error).

4. 2 Collbecchi

`wallet. debit. authorized	rejected`
`wallet. commit. ok	failed`
`wallet. credit. ok	failed`
`rg. blocked` / `rg. limit. hit`
`bonus. state. updated`
`compensation. richired '(protocollo del round)

Idampotenza: chiavi «round _ id», «bet _ id», «settle _ id»; Dedotto sul lato del portafoglio e bridge.

5) Modello evento (Kafka/Pulsar)

Topic base

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

Contratti: Avro/JSON Schema + Registry, versioni semantiche, partizionamento per «tenant _ id», «table _ id», «player _ id».

6) Invarianti in denaro e saghe

La verità di bilanciamento è la piattaforma Ledger; bridge memorizza lo stato delle scommesse/round.

Tutte le transazioni sono idepotenti, con Idempotency-Key.

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

«commit» - annulla l'autorizzazione/restituisce hold;
«credit» è una ripetizione fino al successo;
modifiche manuali dei bilanci non consentite Solo eventi di compensazione.

7) Bonus, tornei, jackpot in live

Il contributo al wager: i giochi live di solito danno il 10-25% del peso; bridge deve trasmettere esplicitamente il tipo di tavolo/gioco.

Tornei/voli: punti per giro, moltiplicatori, streaks; sorgente - eventi 'live. bet. settled`.

Jackpot: fix/progressivo (locale/in rete). Una quota con ogni puntata qualificata; Il trigger è sul lato bridge/jackpot del servizio.

Responsabilità: i meccanici promozionali non devono cambiare le possibilità del gioco principale; altrimenti è una certificazione separata.

8) Antifrode e rischio

Velocity/Arbitraggio ritardi: divieto di scommesse «dopo il fatto»; hard cut-off.

Account multi/dispositivi condivisi: controlli grafici, device-fingerprinting.

Anomalie delle vincite: pattern extra-previsti per tavolo/giocatore/regione.

Chargeback defense: associazione dei tassi con depositi/merchant, logi hold/commit.

9) Osservabilità e telemetria

Metriche aziendali

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

Tecnometriche

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

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

Dashboard

NOC: tavoli/show, online, bets/min, settle lag, errore heatmap per regione.

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

Alert (budget SLO): p95 'settle'> X, errato rate> Y%, lag> Z secondi, altezza 'cancelled'.

Controllo WORM - Modifiche ai limiti, ai profili RTP dei round di spettacolo, alle impostazioni dei jackpot, ai flag fich.

10) Sicurezza e compliance

mTLS + firma (HMAC/EdDSA) su tutte le chiamate S2S; token a breve vita.

Zero-trust: politiche mesh, privilegi minimi, segmentazione per regione.

PCI/GDPR/Data residency: PII e loghi - nella regione (EU/UK/BR...), lettura crociata non consentita.

RG: segnali di stop sincronizzati al tasso di interesse (limiti di deposito/perdita/tempo, auto-esclusione), reality-check.

Controllo: Crit Action Loges - Invariati (WORM), Quattro occhi disponibili.

11) Multiforme e multibrand

Tutti gli eventi e le chiamate sono contrassegnati con «tenant _ id/brand _ id/license/region».

Ledger/Cashier/PII - Isolati per licenza/regione (spesso singoli database/cluster).

Servizi condivisi (bridge kernel, tornei, jackpot) - shareable, ma con RLS rigido nei dati.

Flag Fiech/limiti/bonus-pool - a livello di marchio/giurisdizione.

12) Prestazioni e degrado

Back-pressure - «no new bets» prima del cut-off, priorità commit/settle.

Degrade mode: disattivare promo/jackpot collaterali, mantenere le scommesse core e pagamenti.

Piano DR: asset-asset/asset-passivo; RPO 5 min, RTO 30 min; sincronizzazione outbox.

13) Scontrino di implementazione (operatore/provider)

Architettura

Contratti evento (Schema Registry), chiavi di idempotenente'round _ id/bet _ id/settle _ id '.
Саги authorize→commit→settle→credit; compensazione senza modifiche manuali.
Outbox/CDC per tutti gli stati di cassa; Non ci sono pubblicazioni «a scapito».
Cut-off/lock sono implementati sul lato core live e sono protetti da ritardi di rete.

Denaro/bonus

Ledger come fonte di verità; hold/commit/credit atomon.
Il contributo live al vager è trasparente; tornei/jackpot non cambiano le possibilità del gioco principale.

Observability/SLO

Dashboard NOC/SRE; Alert SLO su latency/errore/lag.
Controllo WORM dei limiti e dei flag Dopo il processo.

Sicurezza/compilazione

mTLS + firma; Vault/HSM; RBAC/ABAC; data residency.
I piedi RG sono sincronizzati; I segnali AML e i rapporti sono automatizzati.

14) Bandiere rosse (anti-pattern)

Modifica manuale dei bilanci/settlement nel database.

Accetta le scommesse dopo la scadenza della finestra (nessun rigido lock).

Pubblicare la telemetria senza outbox/CDC si perdono i round.

La mancanza di idipotenza e di deducibilità ha → i pagamenti.

Combinazione tra PII e contorno in denaro di diverse regioni/marchi.

Nessun degrado, la caduta del promo fa saltare il calcolo delle vincite.

I rapporti di regolazione BI funzionano con OLTP da combattimento.

15) Totale

Bridge per i giochi live non è solo un adattatore API, ma un nucleo di eventi che collega il risultato vivente ai rigorosi invarianti della piattaforma: portafogli, bonus, RG/AML e rendicontazione. La sua forza è nell'idempotenza e nelle saghe, nelle finestre rigide e nei locchi, nella sorveglianza e nella sicurezza predefinita. Su queste basi, il casinò live e i formati di spettacolo sono scalabili prevedibilmente, resistono ai picchi e rimangono trasparenti per il giocatore, il marchio e il regolatore.