Live-Betting-Architektur: Quotenupdates in unter 50ms verarbeiten

Minute 89, Champions-League-Halbfinale. Ein Tor fällt. Innerhalb von 3ms wird jeder betroffene Markt auf der Casino-Plattform ausgesetzt. Innerhalb von 50ms erreichen neu berechnete Quoten 4,2 Millionen verbundene Clients.

Jede Verzögerung in dieser Abfolge öffnet ein Arbitrage-Fenster, das versierte Wettprofis innerhalb von Sekunden ausnutzen.

Feeds mehrerer Sportdatenanbieter in unter 5ms normalisieren

Die Architektur beginnt mit Datenfeeds von Sportdatenanbietern, die Play-by-Play-Ereignisse, Statistik-Updates und vorberechnete Quoten über WebSocket-Verbindungen liefern.

Mehrere Feeds von Spielanbietern decken dieselben Events mit unterschiedlichen Latenzen, Formaten und Zuverlässigkeiten ab. Der Feed-Handler muss:

• Events von 3-5 Providern innerhalb von 5ms nach Eingang in ein kanonisches Format normalisieren
• Konfliktauflösung anwenden, wenn Anbieter sich widersprechen – dem schnellsten Anbieter bei zeitkritischen Ereignissen (Tore, rote Karten) vertrauen und dem genauesten bei statistischen Daten (Ballbesitz, Torschüsse)
• Feed-Abbrüche innerhalb eines Heartbeat-Intervalls erkennen und beheben, typischerweise 1-2 Sekunden
• Jedes Event mit Metadaten zur Anbieter-Latenz versehen, damit nachgelagerte Systeme die Aktualität angemessen gewichten können

Vorberechnete Quotentabellen mit statistischen Echtzeitmodellen kombinieren

Eine Sportwetten-Engine muss Tausende Märkte gleichzeitig innerhalb des Latenzbudgets aktualisieren. Reine Echtzeitberechnung kommt da nicht mit.

Ein hybrider Ansatz bewältigt dieses Volumen:

• Vorberechnete Quotentabellen für häufige Szenarien – „Tor in Minute 75, wenn die Heimmannschaft mit 1 führt“ wird zu einem Lookup, nicht zu einer Berechnung
• Echtzeit-Statistikmodelle für Sonderfälle und In-Play-Mikromärkte, in denen Vorberechnung unpraktikabel ist – ihre Inferenz muss in unter 10ms abgeschlossen sein
• Bayessches Updating passt vorberechnete Baselines mit Live-Daten an und vermeidet eine vollständige Neuberechnung bei jedem Event – das deckt 85% aller Marktaktualisierungen ab

Die verbleibenden 15% der Updates laufen über das Echtzeitmodell. Das Spielerlebnis hängt davon ab, dass beide Pfade im selben Latenzrahmen liefern.

Märkte in unter 5ms aussetzen, um Ausnutzung zu verhindern

Fällt ein Tor oder gibt es eine Rote Karte, müssen alle betroffenen Märkte sofort ausgesetzt werden. Schon 100ms Verzögerung öffnen ein Arbitragefenster, das versierte Wetter finden.

Die eventgetriebene Architektur verteilt Suspendierungssignale über dedizierte Kanäle mit hoher Priorität:

• Aussetzungs-Nachrichten umgehen die normalen Verarbeitungsqueues vollständig – eigener Thread-Pool, eigene Netzwerkpriorität, eigene Fehlerdomäne
• Jede Nachricht trägt eine monoton steigende Sequenznummer, damit nachgelagerte Systeme prüfen können, dass keine fehlt
• Das Aussetzungssignal erreicht die spielerseitige Schicht vor den aktualisierten Quoten, sodass keine Wetten auf veraltete Preise platziert werden können
• Responsible-Gaming-Prüfungen auf ausgesetzten Märkten laufen im selben Prioritätskanal – die Betrugserkennung markiert auffällige Wettmuster in den Sekunden vor der Aussetzung

Bei der Marktaussetzung gibt es null Toleranz für Latenz. Sie ist ein Sicherheitsmechanismus, kein Feature.

Quoten über WebSocket mit Delta-Kompression an Millionen Clients ausliefern

Vollständige Quoten-Snapshots bei jedem Update an Millionen verbundener Clients zu senden, sättigt jedes Netzwerk. Delta-Kompression senkt die Bandbreite um 85-95%.

Die Rendering-Pipeline des Clients:

• Die WebSocket-Verbindung empfängt Delta-Updates und wendet sie auf einen lokalen Quoten-Cache auf dem Gerät des Spielers an
• Optimistic UI lässt Spieler zu den angezeigten Quoten setzen, während die serverseitige Validierung Fairness und regulatorische Konformität sicherstellt
• Die Erkennung veralteter Daten markiert Quoten, die nicht im erwarteten Intervall aktualisiert wurden, und verhindert Wetten auf überholte Preise
• In einer mobilen App schwanken die Netzbedingungen ständig – der Client fordert nach jeder Lücke in der Sequenz einen vollständigen Snapshot an und spielt verpasste Deltas nach, wo möglich

Session-State über Reconnects hinweg während Live-Spielen erhalten

Ein abgebrochener WebSocket während eines Live-Spiels darf keinen verlorenen Wettschein bedeuten. Das Player-Management-System speichert den Zustand des Wettscheins serverseitig, gebunden an die Spielersitzung.

Während eines Champions-League-Finales schnellt die Reconnect-Rate hoch, weil mobile Nutzer zwischen WLAN und Mobilfunk wechseln. Die Session-Schicht muss diese Last abfangen:

• Redis-basierter Session Store mit Lesezugriffen im Sub-Millisekunden-Bereich skaliert unabhängig von der Betting-Engine
• Der Reconnect-Flow holt den aktuellen Wettschein und einen vollständigen Quoten-Snapshot in einem einzigen Round Trip
• Loyalty-Programme und der Free-Spins-Status werden zusammen mit dem Wettschein wiederhergestellt, sodass das Spielerlebnis nahtlos weitergeht
• Der Session-Ablauf richtet sich nach einem 15-Minuten-Idle-Timer statt nach der Trennung – kurze Netzwerkunterbrechungen löschen den State nicht

Responsible-Gaming- und Compliance-Prüfungen in der Live-Pipeline ausführen

Einzahlungslimits, Sitzungstimer und Loss-Chasing-Erkennung laufen innerhalb der Live-Wett-Pipeline, ohne das Spielerlebnis zu beeinträchtigen.

Blockierende Prüfungen (Einzahlungslimits, Selbstsperr-Status) lesen aus In-Memory-Caches und sind in unter 2ms abgeschlossen. Das Verhaltens-Scoring läuft asynchron auf dem Event-Stream und analysiert Spielerpräferenzen und Wettmuster auf Anzeichen problematischen Verhaltens.

Live-Dealer-Spiele und Online-Casino-Spiele auf derselben Casino-Plattform teilen dasselbe Architekturmuster: Eventverarbeitung in Echtzeit, sofortige Propagation des Zustands und nahtlose Integration von Compliance-Prüfungen, die für den Spieler keine spürbare Latenz erzeugen.