Integration von Live-Spielen und Show-Formaten über RGS/Bridge

Vollständiger Artikel

💡 18+. Technisches Material für Operator-Teams, Studios und Aggregatoren. Kein Aufruf zum Spiel. Begriffe: Plattform - PAM/Wallet/Kasse/Boni/RG; RGS - Remote Game Server (der Kern der Spiele des Studios); bridge - die Integrationsschicht zwischen dem Live-Kern des Anbieters und der Plattform/dem Aggregator.

1) Warum brauchen Sie eine Brücke zwischen Live und Plattform

Live-Spiele (Roulette, Blackjack, Baccarat) und Show-Formate (Crazy-/Wheel-/Dice-/Game Show) nutzen den Videostream + das reale Ergebnis. Im Gegensatz zu RNG-Slots:

Das Ergebnis kommt nach dem Schließen des Wettfensters und des physischen Ereignisses (Spin, Kartenöffnung).
Strenge Zeitrahmen (Cut-off) und synchrone Wettlocks sind erforderlich.
Die Berechnung der Auszahlungen erfolgt nach den Tabellen des Live-Spiels, nicht nach dem Kern des Slots.
Sie müssen Ihre Brieftasche, Boni, Turniere, Jackpots, RG/AML sowie Telemetrie/Reporting koordinieren.

Bridge ist ein S2S-Gateway, das Live-Mechanik in einen Plattformvertrag „übersetzt“: Session-Token, Autorisierung und Limits, Wettannahme, Fensterfixierung, Settlement, Entschädigungen, Events und Dashboards.

2) Grundlegende Integrationsarchitektur


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)

Rollen:

Live Engine: steuert die Runde, Timer, Ergebnisse (Händler/GCU).
Bridge: die einzige Integrationsschleife zur Plattform. Synchronisiert Geld und Ereignisse.
Plattform: Quelle der Wahrheit über Balance, Boni, RG/AML, Berichterstattung.

3) Threads und Timing: von der Wette bis zur Auszahlung

3. 1 Lebenszyklus der Runde (vereinfacht)

1. session. create - Überprüfung der Marke/Geo/Alter, Ausgabe von session_token.

2. bet. place - im Fenster der Annahme von Wetten; Überprüfung von RG-Limits, Bonusregeln, Idempotency („Idempotency-Key“).

3. bet. lock - Schließt das Fenster (cut-off). Alle nicht gebundenen Anträge werden abgelehnt.

4. live. outcome - Ergebnis der Live Engine (Roulette: Zahl; Show: Sektor/Multiplikator/Bonusrunde).

5. bet. settle ist ein atomares Settlement: Die Belastung der Wette wird bestätigt, die Gutschrift des Gewinns (durch die Brieftasche).

6. bonus/jackpot/tournament - Beitrag/Auslöser.

7. rollback/compensation - wenn der Kanal ausfällt, aber nur gemäß den Regeln der Runde.

3. 2 Fenster und Verzögerungen

Ziellatenz (Glas-zu-Glas): HLS 2-5 c Segment; WebRTC 200-500 ms.

SLO bridge:

p95 `bet. place`/`bet. lock'<150 ms (ohne Spieler-Netzwerk), p95 'settle' <300 ms nach 'live. outcome', „lost/duplicate settlements“ = 0.

4) Bridge API-Verträge ↔ Plattform (Beispiel)

4. 1 Anfragen von bridge→platforma

„POST/wallet/debit“ - Autorisierung der Wette (idempotent, die Antwort ist hold_id).

„POST/wallet/commit“ - Bestätigung der Abbuchung beim Sperren.

„POST/Wallet/Credit“ ist ein Gewinnguthaben.

„POST/rg/check“ - Einzahlungs-/Verlust-/Zeitlimits, Selbstausschluss.

„POST/bonus/apply“ - Beitrag nach Spielart (e. g., live 10–25%).

`POST /jackpot/contribute	trigger'- Anteil des Einsatzes/Gewinns.
„POST/analytics/event“ - Telemetrie (Runde, Tabelle, Verzögerung, Fehler).

4. 2 Kollbeki platforma→bridge

`wallet. debit. authorized	rejected`
`wallet. commit. ok	failed`
`wallet. credit. ok	failed`
`rg. blocked` / `rg. limit. hit`
`bonus. state. updated`
`compensation. erforderlich'(nach Rundenprotokoll)

Idempotenz: Schlüssel 'round _ id', 'bet _ id', 'settle _ id'; dedup auf der Seite der Brieftasche und Brücke.

5) Ereignismodell (Kafka/Pulsar)

Basis-Topics

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

Verträge: Avro/JSON Schema + Registry, semantische Versionen, Partitionierung nach 'tenant _ id', 'table _ id', 'player _ id'.

6) Monetäre Invarianten und Sagas

Wahrheit durch Balance - Plattform Ledger; bridge speichert die Wett-/Runden-Status.

Alle Geldtransaktionen sind idempotent, mit 'Idempotency-Key'.

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

bei Fail 'commit' - Aufhebung der Autorisierung/Rückgabe von Hold;
bei Faille „credit“ - Wiederholung bis zum Erfolg;
Manuelle Bearbeitung von Salden - verboten; Nur kompensierende Ereignisse.

7) Boni, Turniere, Jackpots in Live

Beitrag zur Wehr: Live-Spiele geben in der Regel 10-25% des Gewichts; bridge ist verpflichtet, die Art des Tisches/Spiels explizit zu vermitteln.

Turniere/Flüge: Punkte pro Umsatz, Multiplikatoren, Streaks; Quelle - Ereignisse' live. bet. settled`.

Jackpots: fix/progressiv (lokal/Netzwerk). Beitrag mit jedem qualifizierten Satz; Auslöser ist auf der Bridge/Jackpot-Service-Seite.

Verantwortung: Promo-Mechaniker sollten die Chancen des Hauptspiels nicht ändern; ansonsten separate Zertifizierung.

8) Betrugsbekämpfung und Risiko

Velocity/Delay Arbitration: Verbot von Wetten „nach der Tat“; harter Cut-Off.

Multi-Account/geteilte Geräte: Graph-Checks, Device-Fingerprinting.

Gewinnanomalien: Über-erwartete Muster pro Tisch/Spieler/Region.

Chargeback defense: Bündel von Wetten mit Einzahlungen/Merchants, Hold/Commit-Logs.

9) Observability und Telemetrie

Geschäftsmetriken

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

Techmetrics

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

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

Dashboards

NOC: Tische/Shows, online, bets/min, settle lag, error heatmap nach Regionen.

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

Alerts (SLO-Budget): p95 'settle'> X, Fehlerrate> Y%, lag> Z sec, Wachstum 'storniert' an einem bestimmten Tisch.

WORM-Audit: Änderungen von Limits, RTP-Profilen von Showrunden, Jackpotparametern, Fitch-Flags.

10) Sicherheit und Compliance

mTLS + Signaturen (HMAC/EdDSA) auf allen S2S-Anrufen; kurzlebige Token.

Zero-Trust: Mesh-Richtlinien, Mindestprivilegien, Segmentierung nach Regionen.

PCI/GDPR/Datenresidenz: PII und Protokolle - in der Region (EU/UK/BR...) sind Cross-Reading verboten.

RG: synchrone Bremsleuchten auf Einsatz (Einzahlungs-/Verlust-/Zeitlimits, Selbstausschluss), Reality-Check.

Audit: Crete Action Logs - unveränderlich (WORM), Vier-Augen-Zugriffe.

11) Multi-Tenant und Multi-Brand

Alle Veranstaltungen und Calls sind mit 'tenant _ id/brand _ id/license/region' gekennzeichnet.

Ledger/Cashier/PII - isoliert per Lizenz/Region (oft einzelne DBs/Cluster).

Gemeinsame Dienste (Bridge-Core, Turniere, Jackpots) - Shareable, aber mit einem harten RLS in den Daten.

Ficha-Flags/Limits/Bonus-Pools - auf Markenebene/Jurisdiktion.

12) Leistung und Degradation

Rückdruck: bei Überlastung - 'keine neuen Wetten' vor dem Cut-off, Commit/Settle-Priorisierung.

Degrade-Modi: Deaktivieren von Nebenpromo/Jackpots, Speichern von Core-Wetten und Auszahlungen.

DR-Plan: Aktiva-Aktiva/Aktiva-Passiva; RPO ≤ 5 Minuten, RTO ≤ 30 Minuten; Synchronisation der Outbox.

13) Checkliste Umsetzung (Betreiber/Anbieter)

Architektur

Event contracts (Schema Registry), idempotence keys' round _ id/bet _ id/settle _ id'.
Саги authorize→commit→settle→credit; Kompensation ohne manuelle Korrekturen.
Outbox/CDC für alle monetären Vermögen; Es gibt keine „Umgehungspublikationen“.
Cut-off/lock sind auf der Seite des Live-Kernels implementiert und durch Netzwerkverzögerungen geschützt.

Geld/Boni

Ledger als Quelle der Wahrheit; hold/commit/credit sind atomar.
Der Live-Beitrag zur Zustellung ist transparent; Turniere/Jackpots ändern nicht die Chancen des Hauptspiels.

Observability/SLO

NOC/SRE Dashboards; SLO-Alerts auf latency/error/lag.
WORM-Audit von Limits und Fitch-Flags; Postmortem-Prozess.

Sicherheit/Compliance

mTLS + Signaturen; Vault/HSM; RBAC/ABAC; data residency.
RG-Füße sind synchron; AML-Signale und Berichte werden automatisiert.

14) Rote Fahnen (Anti-Muster)

Manuelle Korrekturen von Waagen/Settlementen in der DB.

Annahme von Wetten nach Ablauf des Fensters (keine strenge Sperre).

Telemetrie-Veröffentlichung ohne outbox/CDC → „verlorene“ Runden.

Mangel an Idempotenz und Deduplex → doppelte Auszahlungen.

Mischung aus PII und Geldkreislauf verschiedener Regionen/Marken.

Keine Degradierung: Der Rückgang der Promo bringt die Berechnung der Gewinne zum Erliegen.

BI/regulatorische Berichte arbeiten mit Kampf OLTP.

15) Das Ergebnis

Bridge für Live-Spiele ist nicht nur ein „API-Adapter“, sondern ein monetärer Ereigniskern, der das Live-Ergebnis mit den strengen Invarianten der Plattform verbindet: Wallet, Boni, RG/AML und Reporting. Seine Stärke liegt in Idempotenz und Sagas, starren Fenstern und Loci, Beobachtbarkeit und „Standard“ -Sicherheit. Auf einer solchen Grundlage skalieren Live-Casinos und Show-Formate vorhersehbar, halten Spitzensendungen stand und bleiben für den Spieler, die Marke und den Regulator transparent.