Was Latenz im Live-Wetten wirklich bedeutet
Wenn wir 'sub-50ms Quoten-Latenz' sagen, meinen wir eine spezifische Zahl: die p50-Wall-Clock-Zeit zwischen dem Moment, in dem der Quelldaten-Feed (Betradar, Genius Sports, BetGenius) einen aktualisierten Preis in unseren Aggregator publiziert, und dem Moment, in dem dieser Preis in der offenen WebSocket-Verbindung eines Spielers rendert.
Sporbet Softs Produktionszahl ist 47ms p50, 180ms p99, gemessen über alle aktivierten Märkte für alle Partner über ein rollendes 30-Tage-Fenster. Plattformen, die mit 500ms+ p99-Latenz laufen, werden arbitragiert. Plattformen mit 50ms p50 nicht.
Die architektonische Begründung für die Priorisierung der Latenz steht in unserer Integrations-Anatomie.
Redis-Pub/Sub-Fan-out und partitionierte Subscriptions
Das erste Subsystem ist die Fan-out-Schicht. Wenn ein aktualisiertes Preis-Event in unserem Aggregator landet, wird es auf ein Redis-Pub/Sub-Topic republished. Der Topic-Key ist strukturiert: odds:{sport_id}:{league_id}:{market_id}. Die Wahl der Granularität ist wichtig.
Sporbet Softs Partitionsstrategie ist Market-Level für Top-100-Ligen und League-Level für den Long-Tail. Ein Spieler, der den Match-Result-Markt eines Premier-League-Spiels abonniert, abonniert ein Topic und erhält einen Stream von Preisupdates nur für diesen Markt.
Redis ist hier das richtige Werkzeug, weil das Latenzbudget für den Fan-out-Hop unter 5ms liegt. Ein einziger Champions-League-Spieltag pusht 800K Events/Minute durch das Fan-out. Redis-Cluster hält das mit sub-Millisekunden p99-Publish-Latenz aus.
Sticky-Session-WebSockets und die Connection-State-Machine
Das zweite Subsystem ist die WebSocket-Flotte. Jede Spieler-Session öffnet eine einzige langlebige WebSocket-Verbindung zu einem unserer Edge-Gateways. Die Verbindung ist sticky — d. h. von einem Layer-4-Load-Balancer mit konsistentem Hashing auf einem Session-Cookie geroutet.
Die Connection-State-Machine selbst ist interessanter als erwartet. Jede Verbindung hält die abonnierten Topics, die authentifizierte Session des Spielers, die Back-Pressure-Wassermarke und die letzte bestätigte Event-ID. Bei Reconnect — auf Mobilnetzen üblich — fährt der Client von der letzten bestätigten Event-ID fort.
Das gleiche Idempotency-Pattern, das unser Settlement-Engine für Partial-Cashout verwendet, taucht hier auf.
Edge-Cached-Static-Shell und das Time-to-Interactive-Budget
Latenz für eine bestehende Verbindung ist eine Sache. Latenz für den First Paint — die Zeit zwischen dem Spieler-Navigieren zum iframe und dem Sehen frischer Quoten — eine andere. Sporbet Soft erreicht sub-1,5s Time-to-Interactive auf Mobilgeräten, indem es die statische Shell des iframes Edge-cacht.
Die Shell ist ein kleines HTML-Dokument (unter 50KB, gzipped auf etwa 14KB) plus ein JavaScript-Bundle unter 200KB. Beide werden von einem CDN bedient — in unserem Fall Cloudflare — mit aggressiven Cache-Headern.
Die gesamte Sequenz ist so abgestimmt, dass sie Googles INP-Threshold von 200ms mit Margin clear — siehe Sportsbook-Preise für die Faltung in die Pauschalgebühr.
Back-Pressure-Schutz: was passiert, wenn ein Upstream-Feed surge
Live-Quoten-Traffic ist nicht glatt. Eine Rote Karte in der Nachspielzeit beim El Clásico generiert einen 50x-Spike in Preis-Events über ein 30-Sekunden-Fenster. Eine Plattform ohne Back-Pressure-Schutz sieht diese Events sich im WebSocket-Send-Buffer stauen, und schließlich gehen dem Gateway die File-Descriptors aus.
Sporbet Softs Gateways implementieren explizite Back-Pressure mit zwei Mechanismen. Erstens: Per-Connection-Send-Buffer-High-Water-Marks. Zweitens: Fleet-weite Circuit-Breakers.
Kritisch: Back-Pressure führt niemals dazu, dass das Gateway veraltete Quoten akzeptiert. Die Integritäts-Invariante — jede Verbindung sieht eine monoton-nicht-abnehmende Event-Sequenz pro Markt — gilt unter allen Bedingungen.
Multi-Region Active-Active und Sub-Sekunden-Failover
Das letzte Subsystem ist die Failover-Topologie. Sporbet Soft betreibt drei Regionen — EU-West, EU-Central, Middle-East — in Active-Active-Konfiguration. Jede Region hat eine vollständige Kopie der WebSocket-Flotte, des Redis-Clusters, des Aggregators und der Settlement-Engine.
DNS-basiertes Geo-Routing sendet jeden Spieler zu seiner nächstgelegenen Region. Wenn eine Region degradiert, leitet die DNS-Schicht neue Verbindungen innerhalb von 30-60 Sekunden zur nächstnähesten Region um. End-to-End-Failover beträgt unter einer Sekunde sichtbarer Unterbrechung.
Operatoren auf dem iframe — siehe B2B-Sportsbook-iframe — sehen nie ein Wartungsfenster.
Warum API-Polling Sie nicht dorthin bringt
Operatoren, die API-only-Integrationen evaluieren, fragen manchmal, ob sie ähnliche Latenz erreichen können, indem sie einen REST-Quoten-Endpoint mit hoher Frequenz pollen. Die Antwort ist nein, und die Mathematik ist einfach. Ein 100ms-Poll-Intervall ergibt eine Worst-Case-100ms-Freshness-Gap.
Push-basiertes WebSocket-Fan-out skaliert in die andere Richtung: der Vendor sendet ein Event pro Markt-Update unabhängig von der Subscriber-Anzahl. Die Freshness-Gap ist durch Netzwerk-Latenz begrenzt, nicht durch Poll-Intervall.
Wenn Sie einen API-only-Build evaluieren, ist das Live-Wetten-Latenzbudget allein meist genug, um die Entscheidung in Richtung iframe zu schieben — siehe unseren iframe vs API-Vergleich.