Ce que la latence signifie réellement dans le pari live
Quand nous disons « latence de cotes sous 50ms », nous parlons d'un chiffre spécifique : le temps wall-clock p50 entre le moment où le flux source (Betradar, Genius Sports, BetGenius) publie un prix mis à jour dans notre agrégateur et le moment où ce prix s'affiche dans la connexion WebSocket ouverte d'un joueur.
Le chiffre de production Sporbet Soft est 47ms p50, 180ms p99, mesuré sur tous les marchés activés pour tous les partenaires sur une fenêtre roulante de 30 jours. Les plateformes tournant à 500ms+ p99 sont arbitragées. Les plateformes tournant à 50ms p50 ne le sont pas.
La justification architecturale pour prioriser la latence vit dans notre anatomie d'intégration.
Fan-out Redis pub/sub et abonnements partitionnés
Le premier sous-système est la couche de fan-out. Quand un événement de prix mis à jour atterrit dans notre agrégateur, il est republié sur un topic Redis pub/sub. La clé du topic est structurée : odds:{sport_id}:{league_id}:{market_id}. Le choix de la granularité importe.
La stratégie de partition de Sporbet Soft est niveau marché pour les ligues top-100 et niveau ligue pour la longue traîne. Un joueur s'abonnant au marché résultat-match d'un match de Premier League s'abonne à un seul topic et reçoit un flux de mises à jour de prix pour ce marché uniquement.
Redis est le bon outil ici car le budget de latence pour le saut de fan-out est sous 5ms. Une seule semaine de Champions League pousse 800K événements/minute à travers le fan-out. Le cluster Redis soutient cela avec une latence de publication p99 sub-milliseconde.
WebSockets sticky-session et la state machine de connexion
Le deuxième sous-système est la flotte WebSocket. Chaque session joueur ouvre une seule connexion WebSocket à longue durée vers l'un de nos edge gateways. La connexion est sticky — c'est-à-dire routée par un load balancer Layer-4 avec hachage cohérent sur un cookie de session.
La state machine de connexion elle-même est plus intéressante que prévu. Chaque connexion détient les topics abonnés, la session authentifiée du joueur, la marque haute de back-pressure et le dernier ID d'événement acquitté. À la reconnexion — commune sur les réseaux mobiles — le client reprend depuis le dernier ID d'événement acquitté.
Le même pattern d'idempotence que notre moteur de règlement utilise pour le cashout partiel apparaît ici.
Shell statique edge-cached et le budget time-to-interactive
La latence pour une connexion existante est une chose. La latence pour le first paint — le temps entre la navigation du joueur vers l'iframe et la vue de cotes fraîches — en est une autre. Sporbet Soft atteint un time-to-interactive sous 1.5s sur mobile en edge-cachant le shell statique de l'iframe.
Le shell est un petit document HTML (sous 50KB, gzippé à environ 14KB) plus un bundle JavaScript sous 200KB. Les deux sont servis depuis un CDN — Cloudflare dans notre cas — avec des en-têtes de cache agressifs.
Toute la séquence est ajustée pour passer le seuil INP de Google de 200ms avec marge — voir tarification sportsbook pour comment ce budget de performance se plie dans les frais forfaitaires.
Protection back-pressure : ce qui arrive quand un flux upstream surge
Le trafic de cotes live n'est pas lisse. Un carton rouge en arrêts de jeu au El Clásico génère un pic 50x dans les événements de prix sur une fenêtre de 30 secondes. Une plateforme sans protection back-pressure voit ces événements s'accumuler dans le buffer d'envoi WebSocket, et finalement le gateway tombe en panne.
Les gateways Sporbet Soft implémentent du back-pressure explicite avec deux mécanismes. D'abord : marques hautes de buffer d'envoi par connexion. Deuxièmement : circuit breakers à l'échelle de la flotte.
Critique : le back-pressure ne cause jamais au gateway d'accepter des cotes obsolètes. L'invariant d'intégrité — chaque connexion voit une séquence d'événements monotone-non-décroissante pour chaque marché — tient sous toutes les conditions.
Multi-région active-active et failover sous-seconde
Le dernier sous-système est la topologie de failover. Sporbet Soft fait tourner trois régions — EU-West, EU-Central, Middle-East — en configuration active-active. Chaque région a une copie complète de la flotte WebSocket, du cluster Redis, de l'agrégateur et du moteur de règlement.
Le geo-routing basé DNS envoie chaque joueur à sa région la plus proche. Quand une région se dégrade, la couche DNS reroute les nouvelles connexions vers la région suivante la plus proche en 30-60 secondes. Le failover end-to-end est sous une seconde de perturbation visible par l'utilisateur.
Les opérateurs sur l'iframe — voir B2B sportsbook iframe — ne voient jamais une fenêtre de maintenance.
Pourquoi le polling API ne vous y amène pas
Les opérateurs évaluant des intégrations API-only demandent parfois s'ils peuvent atteindre une latence similaire en pollant un endpoint REST de cotes à haute fréquence. La réponse est non, et les maths sont simples. Un intervalle de poll de 100ms donne un worst-case d'écart de fraîcheur de 100ms.
Le fan-out WebSocket push-based échelonne dans l'autre direction : le vendor envoie un événement par mise à jour de marché indépendamment du nombre d'abonnés. L'écart de fraîcheur est borné par la latence réseau, pas par l'intervalle de poll.
Si vous évaluez un build API-only, le budget de latence des paris live est généralement suffisant pour pousser la décision vers iframe — voir notre comparaison iframe vs API.