En la mayoría de software, un bug se reporta, se prioriza y se arregla en el próximo sprint. En apuestas en tiempo real, un bug de dos segundos puede significar un settlement incorrecto sobre dinero real, en vivo, mientras el evento sigue corriendo.
La diferencia no es la complejidad, es la ventana
Un sistema de streaming puede degradarse con gracia: baja la resolución, el usuario espera un poco. Un sistema de apuestas en tiempo real no tiene ese lujo. Si el feed de cuotas se retrasa 400ms respecto al evento real, la ventana de arbitraje ya se abrió y alguien la va a explotar.
- Latencia no es una métrica de performance, es una superficie de riesgo financiero.
- Un rollback no es “revertir código”, es reconstruir el estado de cada apuesta abierta en esa ventana.
- El compliance no se audita al final del sprint, se audita transacción por transacción.
Qué prueba realmente un sistema así
La prueba que importa no es que el endpoint responda. Es que el balance del cliente, la casa y el regulador coincidan después de cualquier secuencia de eventos, incluyendo los que fallan a mitad de camino:
// No alcanza con esto
expect(response.status).toBe(200);
// Esto es lo que realmente hay que probar
expect(await getLedgerBalance(betId)).toEqual(expectedSettlement);
expect(await getAuditTrail(betId)).toBeConsistentAcrossRetries();Por qué esto define el equipo, no solo el código
Un squad que trabaja en este tipo de sistemas necesita entender la regulación tanto como el código: qué se puede reintentar, qué se debe congelar, y qué requiere trazabilidad completa antes de tocar producción. Es ingeniería senior no por el lenguaje o el framework, sino por el costo de estar equivocado.
Cero tolerancia a fallas no es una frase de marketing. Es una restricción de diseño que cambia cómo se escribe cada línea.