O que latência realmente significa em apostas ao vivo
Quando dizemos «latência de odds sub-50ms» queremos dizer um número específico: o tempo wall-clock p50 entre o momento em que o feed fonte (Betradar, Genius Sports, BetGenius) publica um preço atualizado em nosso agregador e o momento em que esse preço renderiza na conexão WebSocket aberta de um jogador.
O número de produção da Sporbet Soft é 47ms p50, 180ms p99, medido em todos os mercados habilitados para todos os parceiros em uma janela rolante de 30 dias. Plataformas rodando com 500ms+ p99 são arbitragiadas. Plataformas rodando com 50ms p50 não são.
A justificativa arquitetônica para priorizar latência vive em nossa anatomia de integração.
Fan-out Redis pub/sub e subscriptions particionadas
O primeiro subsistema é a camada de fan-out. Quando um evento de preço atualizado pousa em nosso agregador, é republicado em um topic Redis pub/sub. A chave do topic é estruturada: odds:{sport_id}:{league_id}:{market_id}. A escolha de granularidade importa.
A estratégia de partição da Sporbet Soft é nível mercado para top-100 ligas e nível liga para a cauda longa. Um jogador subscrevendo ao mercado resultado-partida de um jogo da Premier League subscreve a um topic e recebe um stream de atualizações de preço apenas para esse mercado.
Redis é a ferramenta certa aqui porque o orçamento de latência para o salto de fan-out é abaixo de 5ms. Uma única rodada da Champions League empurra 800K eventos/minuto pelo fan-out. O cluster Redis sustenta isso com latência de publicação p99 sub-milissegundo.
WebSockets sticky-session e a state machine de conexão
O segundo subsistema é a frota WebSocket. Cada sessão de jogador abre uma única conexão WebSocket de longa duração para um de nossos edge gateways. A conexão é sticky — isto é roteada por um load balancer Layer-4 com hashing consistente em um cookie de sessão.
A state machine de conexão em si é mais interessante do que esperado. Cada conexão mantém os topics subscritos, a sessão autenticada do jogador, a marca de água de back-pressure e o último ID de evento reconhecido. Em reconexão — comum em redes móveis — o cliente retoma a partir do último ID de evento reconhecido.
O mesmo padrão de idempotência que nosso motor de liquidação usa para cashout parcial aparece aqui.
Shell estático edge-cached e o orçamento time-to-interactive
Latência para uma conexão existente é uma coisa. Latência para o first paint — o tempo entre o jogador navegar para o iframe e ver odds frescas — é outra. Sporbet Soft atinge time-to-interactive sub-1.5s em mobile fazendo edge-cache do shell estático do iframe.
O shell é um documento HTML pequeno (abaixo de 50KB, gzipped para cerca de 14KB) mais um bundle JavaScript abaixo de 200KB. Ambos são servidos de um CDN — Cloudflare no nosso caso — com headers de cache agressivos.
Toda a sequência é afinada para passar o threshold INP do Google de 200ms com margem — ver preços sportsbook para como esse orçamento de performance se dobra na taxa fixa.
Proteção back-pressure: o que acontece quando um feed upstream surge
Tráfego de odds ao vivo não é suave. Um cartão vermelho nos acréscimos no El Clásico gera um spike 50x em eventos de preço em uma janela de 30 segundos. Uma plataforma sem proteção back-pressure vê esses eventos enfileirarem no buffer de envio WebSocket, e eventualmente o gateway fica sem file descriptors e cai.
Os gateways da Sporbet Soft implementam back-pressure explícito com dois mecanismos. Primeiro: marcas de água altas de buffer de envio por conexão. Segundo: circuit breakers no nível de frota.
Crítico: back-pressure nunca faz o gateway aceitar odds obsoletas. O invariante de integridade — toda conexão vê uma sequência de eventos monotonamente-não-decrescente por mercado — vale sob todas as condições.
Multi-região active-active e failover sub-segundo
O último subsistema é a topologia de failover. Sporbet Soft roda três regiões — EU-West, EU-Central, Middle-East — em configuração active-active. Cada região tem uma cópia completa da frota WebSocket, do cluster Redis, do agregador e do motor de liquidação.
Geo-routing baseado em DNS envia cada jogador para sua região mais próxima. Quando uma região degrada, a camada DNS reroteia novas conexões para a próxima região mais próxima dentro de 30-60 segundos. Failover end-to-end é abaixo de um segundo de disrupção visível ao usuário.
Operadores no iframe — ver B2B sportsbook iframe — nunca veem uma janela de manutenção.
Por que polling API não te leva lá
Operadores avaliando integrações API-only às vezes perguntam se podem atingir latência similar fazendo polling em um endpoint REST de odds em alta frequência. A resposta é não, e a matemática é direta. Um intervalo de poll de 100ms dá uma brecha de frescor worst-case de 100ms.
Fan-out WebSocket push-based escala na outra direção: o vendor envia um evento por atualização de mercado independente da contagem de assinantes. A brecha de frescor é limitada pela latência de rede, não pelo intervalo de poll.
Se você está avaliando um build API-only, o orçamento de latência de apostas ao vivo sozinho é geralmente suficiente para empurrar a decisão para iframe — ver nossa comparação iframe vs API.