Qué significa realmente «determinista» en la capa de liquidación
La liquidación determinista es un contrato: el mismo input siempre debe producir el mismo output, para siempre. Dado un registro de apuesta y un registro de resultado oficial, la función de liquidación devuelve uno de tres valores — settled, void, pending_review. Sin timestamps en la lógica, sin llamadas a Math.random(), sin lecturas de estado mutable compartido.
Suena obvio hasta que ves con qué frecuencia se viola en producción. Un worker que lee el cache de cuotas para calcular un reembolso de void no es determinista. Más contexto en nuestra anatomía de integración.
El motor Sporbet Soft impone el determinismo tratando la liquidación como una función pura de dos argumentos — versionada y reproducible.
Paso uno: validación de feed fuente antes de la ejecución
Antes de que la función de liquidación se ejecute, el motor valida el resultado oficial. El resultado llega desde uno de los feeds primarios (Sportradar/Betradar, Genius Sports, BetGenius) más un cross-check opcional de un feed secundario. La capa de validación rechaza resultados que fallan en cualquiera de cinco puertas. Los puntajes atípicos son marcados. Los puntajes conflictivos entre dos feeds se encolan para revisión de trading. Los resultados que llegan antes del umbral de fin oficial (típicamente el minuto 85 para el fútbol) se retienen.
Solo después de que un resultado pasa las cinco puertas se convierte en input de liquidación. Esto suena a overhead hasta que recuerdas que un mal evento de feed que auto-liquida un mercado en el sentido equivocado puede costarle al operador más que la cuota de vendor trimestral.
Paso dos: búsqueda de plantilla de mercado y selección de función
Cada mercado que el sportsbook ofrece está respaldado por una plantilla de mercado versionada: un documento JSON que captura el nombre del mercado, sus selecciones, sus parámetros y — críticamente — una referencia a la función de liquidación que sabe cómo liquidarlo. Un mercado 1X2 tiempo completo apunta a settle_1x2_ft. Un handicap asiático -1.25 apunta a settle_asian_handicap con el parámetro de línea horneado en el bet record.
La plantilla está versionada porque las definiciones de mercado cambian. Cuando una liga cambia de muerte súbita a un formato de prórroga de dos períodos, la plantilla correspondiente envía una nueva versión. Una apuesta de cinco años todavía se liquida bajo las reglas que aplicaban el día en que se colocó.
Paso tres: ejecución de función y logging reproducible
Con el resultado validado y la plantilla seleccionada, la función de liquidación se ejecuta. La función es un pedazo de código casi puro — toma la apuesta, el resultado y opcionalmente el intento de liquidación previo, y devuelve la decisión más el monto del pago. Sin I/O, sin lecturas de reloj, sin números aleatorios.
Cada ejecución escribe un evento de liquidación en el audit log append-only. Sporbet Soft empareja el audit log con un arnés de replay sintético que vuelve a ejecutar cada liquidación cada noche contra las últimas versiones de función y señala cualquier drift. En cuatro años de operación hemos atrapado dos bugs reales de liquidación de esa manera antes de que ningún cliente los notara.
Semántica de void e inmutabilidad de selecciones ya liquidadas
El void es donde los motores de liquidación ingenuos se caen. La interpretación intuitiva — «un partido fue anulado, así que revirtamos todo» — es peligrosa. Si un jugador colocó un acumulador de cuatro patas y la tercera pata ya ha sido liquidada y acreditada, anular retroactivamente el partido entero forzaría al motor a clawback crédito de una wallet que desde entonces ha sido gastada o retirada.
La regla Sporbet Soft es explícita: las selecciones ya liquidadas son inmutables ante void. Cuando un partido es anulado, el motor void solo las selecciones que aún están pending en el momento en que el void se procesa; las selecciones ya settled permanecen settled, y el pago multi-bet se recalcula tratando la pata anulada como una «pata void» con cuota efectiva 1.00.
Por las reglas de finalización controladas por el operador — ver controles de riesgo operador — el void requiere un código de razón de una taxonomía fija y un ID de usuario operador.
Recálculo multi-bet y reconciliación de cashout parcial
El recálculo multi-bet es una de las características de mayor apalancamiento en el motor. Cuando una sola pata de un acumulador se liquida, el motor no espera a que toda la apuesta esté lista — recalcula incrementalmente la exposición de la apuesta y la responsabilidad abierta del operador.
El cashout parcial agrega un segundo eje. Un jugador que cashea 40 % de un acumulador de cuatro patas después de dos patas ganadas deja 60 % de la apuesta activa; el motor debe reconciliar el cashout 40 % contra la wallet, marcar 60 % del stake original como aún-en-riesgo y continuar recalculando el multi.
El desafío de ingeniería no son las matemáticas, es la concurrencia. Sporbet Soft usa claves de idempotencia derivadas del ID de apuesta, ID de pata y contador de intento — ver nuestra arquitectura de latencia de cuotas.
Resolución de disputa: el enlace de audit-trail es la respuesta
Un flujo de resolución de disputa que requiere un mensaje de Slack del trading floor escala como un mensaje de Slack — nada. El modelo Sporbet Soft es que cada disputa comienza y termina en el enlace de audit-trail de la apuesta en el partner panel. El enlace muestra en una pantalla: el registro de apuesta, el snapshot de wallet del jugador, el resultado de feed validado, la versión de la plantilla, la versión de la función, la decisión, el pago, cada evento de cashout, cada evento de void y un botón de replay de un solo clic.
En cuatro años de operación el tiempo promedio de resolución de una disputa de liquidación en Sporbet Soft es bajo dos minutos; el benchmark de industria comparable en plataformas tier-1 con liquidación no-reproducible está más cerca de dos días.
Estos detalles son lo que el iframe esconde de tus ingenieros.