Arquitectura de límites: diseñando controles de riesgo que realmente escalan

Contexto: por qué “límites” es infraestructura crítica

Un sistema de límites no es una pantalla de configuración ni un agregado post-trade. Es un plano de enforcement que debe ejecutarse en la ruta crítica de cada decisión (precio, aceptación, stake, cashout, exposición) y hacerlo con consistencia atómica, conciencia inter-mercado y propagación en tiempo real.

Esto alinea con la tesis de que el riesgo operativo se materializa en controles ejecutables, no en reporting: ver /es/insights/estrategia/el-riesgo-no-es-un-dashboard-es-un-motor-de-enforcement.

Objetivos de diseño (Infrastructure-first)

Enforce atómico en la ruta crítica

Cada operación que incremente riesgo debe pasar por un gate determinístico.
La decisión de aceptar/rechazar debe ser linealizable respecto al estado de exposición relevante.
Evitar “best effort” y compensaciones posteriores como mecanismo primario.

Consistencia inter-mercado y cross-product

Los límites deben poder expresarse en términos de:
- evento (todas las selecciones/mercados de un evento),
- competición/temporada,
- cliente (por cuenta, grupo, segmento),
- counterparty (afiliado, canal, región),
- producto (pre-match, in-play, same-game parlay, exchange-like, etc.).
La exposición debe consolidarse con un modelo común para poder propagar restricciones a múltiples motores (pricing, trading, anti-fraude).

Propagación en tiempo real

Un cambio de política (p. ej., bajar max stake por señal de trading) debe hacerse efectivo en milisegundos a segundos, no minutos.
La latencia de control se trata como SLO de plataforma, no como “feature”.

Modelo de dominios: límites como política + estado

Política (declarativa)

Definir límites como reglas versionadas:

Scopes: customer, event, market, selection, channel.
Dimensions: maxStake, maxPayout, maxLoss, maxExposure, velocity.
Conditions: tiempo (in-play vs pre), precio/odds, perfil, riesgo del mercado.
Actions: reject, capStake, requote, requireManualReview, throttle.

Recomendación: DSL/JSON con versionado y “effectiveAt” para rollout controlado y auditoría.

Estado (materializado)

Separar la intención (política) del estado operativo:

Exposición agregada por clave de riesgo (ej. eventId+side, customerId+eventId).
Contadores de velocidad (sliding windows).
Reservas (holds) en curso para garantizar atomicidad en alta concurrencia.

Enforcement atómico: patrón de “reserva + commit”

Flujo mínimo (síncrono)

Quote/Request entra al Risk Gateway.
Evalúa política aplicable (cache + invalidación).
Calcula impacto incremental (delta) y consulta exposición actual.
Realiza reserva atómica (hold) en el store de límites.
Devuelve decisión: accept/cap/reject (+ razón y límites efectivos).
En confirmación, commit; si expira/cancela, release.

Por qué “hold” es obligatorio

Sin reserva, dos apuestas concurrentes pueden sobrepasar límites aunque cada una “parezca” válida al momento de lectura. El hold convierte el límite en un recurso contendido con semántica de concurrencia clara.

Implementación típica de atomicidad

Store con operaciones atómicas por clave (Redis con scripts Lua, DynamoDB con conditional writes, FoundationDB, etc.).
Claves de riesgo diseñadas para minimizar hot spots sin romper agregación.
TTL para holds + idempotencia por requestId.

Conciencia inter-mercado: agregación de exposición y netting

Normalización de riesgo

Para escalar, el sistema requiere una representación común:

Exposición por resultado (p. ej., “Team A win”) y por combinaciones (SGP).
Conversión a métricas operativas: liability, payout, worst-case.
Netting controlado: reglas explícitas sobre qué se netea y qué no (in-play puede requerir conservadurismo).

Jerarquías de límites (stack de controles)

Aplicar límites en cascada:

Límites regulatorios/KYC (hard stop).
Límites de cliente (responsible gaming + riesgo comercial).
Límites de evento/mercado (liquidez).
Límites de book (capital at risk).
Límites de velocidad/abuso.

La decisión final se compone por el mínimo estricto entre cap y hard stops, con trazabilidad.

Propagación en tiempo real: control-plane vs data-plane

Control-plane (configuración y señales)

Servicio de políticas, versionado, aprobación, auditoría.
Señales desde trading: suspensión, reducción de límites, “sharp action”, cambios por incidentes.
Distribución: stream (Kafka/PubSub) + cache local con invalidación.

Data-plane (enforcement)

Risk Gateway co-localizado con el motor de aceptación para latencia mínima.
Dependencias limitadas y degradación controlada:
- Si falla el control-plane, operar con última política válida.
- Si falla el store de atomicidad, definir postura explícita: fail-closed para riesgo financiero; excepciones solo con guardrails y aprobación.

Latencia, disponibilidad y degradación: SLOs operativos

SLOs recomendados

P95 de decisión de límites: objetivo sub-10ms en región (dependiendo del store).
Disponibilidad del enforcement: >= 99.95% (porque está en la ruta crítica).
Propagación de cambios: objetivo sub-1s para suspensiones y recortes.

Estrategias de resiliencia

Multi-AZ con store replicado.
Backpressure y rate limiting upstream.
Circuit breakers diferenciados:
- pricing puede degradar a “no quote”.
- bet acceptance típicamente debe fail-closed o cap agresivo.

Observabilidad y auditoría: evidencia, no dashboards

Telemetría mínima (estructurada)

Decisión por solicitud: regla aplicada, versión, scope, clave, delta, exposición antes/después.
Motivo codificado (enum) para análisis sin parsing.
Métricas de contención: locks/hot keys, ratio de caps/rejects, expiración de holds.

Auditoría

Event sourcing de cambios de política y overrides.
Reproducibilidad: poder “replay” una decisión dado estado/política/versiones.
Trazabilidad por correlationId (cliente/evento/request).

Anti-patrones que impiden escalar

Límites como lógica dispersa

Si pricing, trading y acceptance implementan “su propia versión” del límite, aparecen divergencias y ventanas de arbitraje. Centralizar enforcement y exponer decisiones como API determinística.

Lectura eventual sin reservas

La exposición eventual sirve para analytics, no para gating financiero en tiempo real.

Configuración manual sin versionado

Sin versionado + aprobación + effectiveAt, no hay control operacional ni forensics.

Implicaciones de build vs buy (sin simplificaciones)

La decisión relevante no es “build vs buy” sino qué componentes deben ser nativos por estar en la ruta crítica (gateway, store de atomicidad, modelo de claves, SLOs) y qué puede integrarse (UI, workflows, reporting). Marco general en /es/insights/estrategia/build-vs-buy-es-la-pregunta-equivocada-en-estrategia-de-sportsbooks y contexto adicional en /es/insights.

Key takeaways

Un sistema de límites escalable exige enforcement atómico con holds y commits idempotentes.
La conciencia inter-mercado requiere un modelo común de exposición y reglas explícitas de netting.
Separar control-plane (políticas/señales) de data-plane (decisión en ruta crítica) es clave para latencia y resiliencia.
Sin versionado, auditoría y telemetría estructurada, los límites no son operables bajo estrés.