Proyecto corporativo · Presentado sin referencias a la empresa: solo arquitectura y decisiones.
Pipeline orientado a eventos: recepción, validación y registro de apuestas
La apuesta se acepta y se encola. Se revisan los límites y el historial del jugador y luego la apuesta aceptada se entrega a la API de apuestas del motor en vivo, que la inserta en la BD en vivo.
Haz clic en un paso para saltar a él. Haz clic en un componente para ver detalles.
Suite de microservicios backend para un operador de apuestas deportivas en línea. Recibe apuestas pregame y en vivo, las valida contra límites del jugador y cuotas vigentes, las persiste en el libro de apuestas y devuelve cada cambio de estado al front-end en tiempo real. Las apuestas en vivo añaden límites con historial revisados bajo bloqueo por jugador y luego una entrega idempotente a la API de apuestas del motor en vivo.
Una ruta monolítica y síncrona de inserción de apuestas no soportaba los picos de tráfico de eventos, no daba retroalimentación al jugador durante la validación y ataba las reglas de límites a un modelo heredado de procedimientos almacenados, difícil de probar y evolucionar. El operador necesitaba desacoplar recepción, validación y persistencia, mantener orden estricto por jugador e introducir reglas de límites en vivo más ricas sin romper el libro de apuestas heredado.
01
El desacople permite que la API responda al instante, absorbe picos en días de eventos y deja que cada etapa escale y falle de forma independiente. Los mensajes se particionan por jugador para preservar el orden por cuenta, con commits manuales de offsets y reintentos acotados.
02
Mantener las reglas libres de dependencias HTTP, de base de datos y de Kafka las hace totalmente probables y reutilizables en servidor y navegador. Quien llama aporta una instantánea del historial; el motor solo decide. Las versiones se fijan explícitamente para revalidar juntos los cambios de contrato.
03
Una apuesta en vivo se revalida contra la instantánea de límites más reciente y otra vez bajo un bloqueo por jugador, de modo que apuestas concurrentes no superen en conjunto los topes por juego. El endpoint público de pre-verificación es explícitamente preliminar.
04
Cada servicio emite los cambios de estado de la apuesta a un solo tópico; un único hub los distribuye a los clientes. Los servicios nunca hablan directo con el front-end, lo que los mantiene sin estado y escalables horizontalmente.
05
Reimplementar años de reglas del libro era más riesgoso que encapsularlas. La biblioteca heredada se aloja tras una API HTTP, dando al nuevo pipeline un contrato estable mientras las reglas se migran funcionalidad por funcionalidad.
06
Todas las llamadas externas (cuotas, perfil de jugador, API heredada) usan clientes tipados con políticas de reintento, timeout y circuit breaker. Los fallos se traducen en claves de error de negocio explícitas en lugar de pérdidas silenciosas.