Contexto regulatorio: “reproducir estado” es una evidencia, no un lujo
En un sportsbook regulado, la auditoría no busca “plausibilidad”; busca reproducibilidad: volver a ejecutar el sistema (o un modelo verificable de su ejecución) y obtener el mismo estado para un instante de tiempo dado. Sin esto, no puedes demostrar de forma determinística:
- qué precios estaban vigentes,
- qué inputs llegaron (y en qué orden),
- qué controles de riesgo aplicaron,
- por qué se aceptó/rechazó una apuesta,
- qué exposición real existía cuando se movió una línea.
La reproducibilidad es un primitivo de control comparable al ledger en pagos. Si el estado no se puede reconstruir, la organización queda expuesta a disputas regulatorias y a litigios donde la carga de prueba se vuelve operativa y no técnica. Para una base conceptual del problema, ver también /es/insights/ingenieria/el-determinismo-como-ventaja-competitiva-en-trading-regulado.
Qué significa “estado” en un sportsbook (y por qué es difícil)
“Estado” no es solo base de datos. En trading y riesgo incluye:
- Market state: feed de pricing, suspensiones, timers, reglas por deporte/competición.
- Risk state: límites, exposición por cliente/segmento/mercado, throttles, degradaciones.
- Order/Bet state: solicitudes, validaciones, decisiones, confirmaciones, retries.
- External state: proveedores de datos, KYC/AML, antifraude, pagos, latencia de red.
- Operational state: deploy version, feature flags, configuración efectiva, incident toggles.
Reproducir estado implica capturar y re-ejecutar el grafo completo de dependencias con orden total (o al menos un orden causal consistente) y con las mismas versiones/configuraciones.
Por qué la mayoría no puede: fallos sistémicos típicos
1) Arquitecturas event-driven sin event sourcing real
Muchos sistemas “publican eventos” pero no tienen un log autoritativo:
- se persisten snapshots en DB, pero no el stream completo de mutaciones,
- se retienen eventos solo para observabilidad, no como fuente de verdad,
- no existe un “replay contract” (semántica de re-ejecución).
Resultado: ante auditoría, solo hay estados finales y métricas, no una historia verificable.
2) No determinismo por concurrencia, timing y orden de llegada
En sportsbook, milisegundos importan. Si la lógica depende de:
- clocks de máquina (wall-clock),
- orden de llegada de mensajes (no ordenado globalmente),
- paralelismo no controlado (race conditions en locks/caches),
dos ejecuciones no producen el mismo estado. El síntoma común: “no podemos reproducir el incidente; fue un edge-case”.
3) Estado distribuido implícito: caches, flags y configuración “viva”
- caches (Redis/local) que afectan decisiones de aceptación,
- feature flags cambiados manualmente sin “config ledger”,
- reglas ajustadas en caliente por traders (sin versionado y sin timestamp consistente).
Sin un registro inmutable de config efectiva por decisión, la reconstrucción se convierte en reconstrucción “forense” (y disputable).
4) Integraciones externas no grabadas: el agujero de la causalidad
KYC, antifraude, proveedores de scoring, datos de partido: si no se registran:
- request/response completos,
- latencia y retries,
- timeouts y fallbacks,
no puedes demostrar qué input recibió el motor al decidir. En regulado, “el proveedor estaba caído” no es evidencia si no se puede reproducir el comportamiento.
5) Persistencia por “modelo de dominio” sin ledger de decisiones
Guardar “bet = accepted” no basta. Se requiere:
- decision record (inputs + reglas + versión + outputs),
- motivos (qué límite disparó, qué exposición se consultó),
- proof trail (hash/ids de eventos usados).
Sin esto, el sistema es una caja negra con estados mutables.
6) Observabilidad ≠ auditabilidad
Logs y traces ayudan a debug, pero suelen fallar como evidencia porque:
- son best-effort (pueden faltar),
- no tienen consistencia transaccional con la decisión,
- no están normalizados ni firmados,
- se rotan y agregan (pierden granularidad).
Auditar requiere un artefacto completo, ordenado e inmutable.
Patrones que bloquean la reproducibilidad en trading y riesgo
Acoplar precio y aceptación a “tiempo real” sin un clock lógico
Si el pricing cambia y la aceptación evalúa “lo último que hay”, sin un clock lógico (o sin pin de versión de feed), el resultado depende del scheduling. Una reconstrucción posterior no puede decidir cuál era “lo último” en ese momento.
Reglas de límites dispersas y no versionadas
Los límites suelen crecer orgánicamente: por vertical, por país, por canal, por VIP, por deporte. Si la regla está en:
- código,
- config,
- una tabla editable,
- una hoja operativa,
sin versionado y sin evaluación reproducible, el porqué de una decisión no es demostrable. Relacionado: /es/insights/estrategia/arquitectura-de-limites-disenando-controles-de-riesgo-que-escalan.
Compensaciones con “eventual consistency” en exposición
Cuando la exposición se calcula de forma eventual (por agregaciones asíncronas), la aceptación puede basarse en un número que cambia retrospectivamente. Si no hay una lectura consistente (o un snapshot identificable), no se puede replicar la decisión.
Qué se necesita para reproducir estado: requisitos de infraestructura
1) Log autoritativo, inmutable y reejecutable
- Un stream de eventos como fuente de verdad (append-only).
- Identificadores estables, ordenamiento y versionado de esquemas.
- Capacidad de replay determinístico por rango temporal y por entidad (market/customer).
La pregunta operativa: ¿puedo reconstruir el estado exacto del motor a T, solo con el log y el código/versiones?
2) Determinismo explícito: clocks, seeds, orden y side effects
- Clock lógico / timestamps monotónicos por partición.
- Orden causal: particionar por clave correcta (market, betslip, customer) y definir invariantes.
- Prohibir side effects no registrados (p. ej., lecturas a cache que cambian decisión).
- Registrar seeds/inputs cuando haya aleatoriedad (idealmente evitarla en core).
3) “Decision ledger” por apuesta (audit record)
Por cada decisión de aceptar/rechazar/price-change:
- inputs: snapshot ids (feed, config, exposure snapshot),
- reglas evaluadas + versión,
- resultado + motivos codificados,
- ids de eventos consumidos,
- hash/firma del record (integridad).
Esto convierte auditoría en verificación, no en interpretación.
4) Versionado completo: código, config, modelos y dependencias
- Build id / commit + artefacto inmutable.
- Config ledger (feature flags, parámetros, overrides manuales).
- Versionado de modelos (si hay ML) y de tablas de reglas.
- Compatibilidad para replay de versiones históricas (o emulación contractual).
5) Captura de IO externo y política de re-ejecución
- “Record & replay” de requests/responses a sistemas externos relevantes.
- Definir qué se considera input regulatorio (p. ej., feed deportivo) y retenerlo.
- Si no se puede grabar por contrato, establecer un proxy/audit gateway.
6) Retención, coste y gobernanza
La reproducibilidad es cara si se diseña tarde. Necesitas:
- retención por obligación regulatoria,
- compresión y particionado por clave,
- políticas de acceso (cadena de custodia),
- capacidad de export “audit pack” por incidente/mercado.
Para más contexto operativo y patrones relacionados, ver el índice general de insights: /es/insights.
Consecuencia práctica: sin reproducibilidad, no puedes demostrar “qué pasó”
En incidentes típicos (línea errónea, aceptación fuera de límites, suspensión tardía), la narrativa sin determinismo se basa en:
- logs incompletos,
- heurísticas de correlación,
- reconstrucción manual de exposiciones,
- suposiciones sobre orden de eventos.
Bajo regulación, eso no es suficiente. La reproducibilidad reduce el espacio de disputa: convierte el “creemos que” en “podemos volver a ejecutar y obtener exactamente lo mismo”.
Key takeaways
- La reproducibilidad de estado es un primitivo de auditoría: sin replay determinístico no hay prueba verificable.
- El principal bloqueo no es “falta de logs”; es no determinismo (orden, clocks, concurrencia, estado implícito).
- Se requiere un log autoritativo + decision ledger con versionado de código/config/modelos e IO externo capturado.
- Observabilidad ayuda, pero no sustituye un diseño infrastructure-first orientado a replay.