Qué significa realmente la latencia en apuestas live
Cuando decimos «latencia de cuotas sub-50ms» nos referimos a un número específico: el tiempo wall-clock p50 entre el momento en que el feed fuente (Betradar, Genius Sports, BetGenius) publica un precio actualizado en nuestro agregador y el momento en que ese precio se renderiza en la conexión WebSocket abierta de un jugador.
El número de producción de Sporbet Soft es 47ms p50, 180ms p99, medido sobre todos los mercados habilitados para todos los partners en una ventana rodante de 30 días. Las plataformas corriendo con 500ms+ p99 son arbitrajadas. Las plataformas corriendo con 50ms p50 no.
La justificación arquitectónica para priorizar la latencia vive en nuestra anatomía de integración.
Fan-out Redis pub/sub y suscripciones particionadas
El primer subsistema es la capa de fan-out. Cuando un evento de precio actualizado aterriza en nuestro agregador, se republica en un topic Redis pub/sub. La clave del topic está estructurada: odds:{sport_id}:{league_id}:{market_id}. La elección de granularidad importa.
La estrategia de partición de Sporbet Soft es a nivel de mercado para las top-100 ligas y a nivel de liga para la cola larga. Un jugador suscribiéndose al mercado de resultado de un partido de Premier League se suscribe a un topic y recibe un flujo de actualizaciones de precio solo para ese mercado.
Redis es la herramienta correcta aquí porque el presupuesto de latencia para el salto de fan-out está bajo 5ms. Una sola semana de partidos de Champions League empuja 800K eventos/minuto a través del fan-out. El cluster Redis sostiene eso con latencia de publicación p99 sub-milisegundo.
WebSockets sticky-session y la state machine de conexión
El segundo subsistema es la flota WebSocket. Cada sesión de jugador abre una sola conexión WebSocket de larga duración a uno de nuestros edge gateways. La conexión es sticky — es decir enrutada por un load balancer Layer-4 con hashing consistente sobre una cookie de sesión.
La state machine de conexión en sí es más interesante de lo esperado. Cada conexión mantiene los topics suscritos, la sesión autenticada del jugador, la marca de agua de back-pressure y el último ID de evento reconocido. En reconexión — común en redes móviles — el cliente reanuda desde el último ID de evento reconocido.
El mismo patrón de idempotencia que nuestro motor de liquidación usa para cashout parcial aparece aquí.
Shell estático edge-cached y el presupuesto time-to-interactive
La latencia para una conexión existente es una cosa. La latencia para el first paint — el tiempo entre que un jugador navega al iframe y ve cuotas frescas — es otra. Sporbet Soft alcanza time-to-interactive sub-1.5s en móvil edge-cacheando el shell estático del iframe.
El shell es un documento HTML pequeño (bajo 50KB, gzippeado a aproximadamente 14KB) más un bundle JavaScript bajo 200KB. Ambos se sirven desde un CDN — Cloudflare en nuestro caso — con headers de cache agresivos.
Toda la secuencia está afinada para pasar el threshold INP de Google de 200ms con margen — ver precios sportsbook para cómo ese presupuesto de rendimiento se pliega en la tarifa plana.
Protección back-pressure: qué pasa cuando un feed upstream se dispara
El tráfico de cuotas live no es suave. Una tarjeta roja en tiempo de descuento en El Clásico genera un spike 50x en eventos de precio sobre una ventana de 30 segundos. Una plataforma sin protección back-pressure ve esos eventos acumularse en el buffer de envío WebSocket, y eventualmente el gateway se queda sin file descriptors y se cae.
Los gateways de Sporbet Soft implementan back-pressure explícito con dos mecanismos. Primero: marcas de agua altas de buffer de envío por conexión. Segundo: circuit breakers a nivel de flota.
Crítico: el back-pressure nunca causa que el gateway acepte cuotas obsoletas. El invariante de integridad — cada conexión ve una secuencia de eventos monótonamente-no-decreciente por mercado — se mantiene bajo todas las condiciones.
Multi-región active-active y failover sub-segundo
El último subsistema es la topología de failover. Sporbet Soft corre tres regiones — EU-West, EU-Central, Middle-East — en configuración active-active. Cada región tiene una copia completa de la flota WebSocket, el cluster Redis, el agregador y el motor de liquidación.
El geo-routing basado en DNS envía cada jugador a su región más cercana. Cuando una región se degrada, la capa DNS rerutea nuevas conexiones a la siguiente región más cercana dentro de 30-60 segundos. El failover end-to-end es bajo un segundo de disrupción visible al usuario.
Los operadores en el iframe — ver B2B sportsbook iframe — nunca ven una ventana de mantenimiento.
Por qué el polling API no te lleva allí
Los operadores evaluando integraciones API-only a veces preguntan si pueden alcanzar latencia similar polleando un endpoint REST de cuotas a alta frecuencia. La respuesta es no, y la matemática es directa. Un intervalo de poll de 100ms da una brecha de frescura worst-case de 100ms.
El fan-out WebSocket push-based escala en la otra dirección: el vendor envía un evento por actualización de mercado independientemente del conteo de suscriptores. La brecha de frescura está acotada por latencia de red, no por intervalo de poll.
Si estás evaluando un build API-only, el presupuesto de latencia de apuestas live por sí solo suele ser suficiente para empujar la decisión hacia iframe — ver nuestra comparación iframe vs API.