Patrones de diseño de ingeniería de software para sistemas de trading
Event sourcing, CQRS y patrones de arquitectura usados por los exchanges
Por qué importan los patrones en los sistemas de trading
El software financiero falla de formas caras: órdenes duplicadas, saldos inconsistentes, fallos parciales silenciosos. Los patrones de diseño no son trofeos — son respuestas a modos de fallo recurrentes: event sourcing para la auditabilidad, CQRS para escalar las lecturas de forma distinta a las escrituras, cortacircuitos (circuit breakers) para detener fallos en cascada, e idempotencia para que los reintentos no dupliquen operaciones.
Pub/Sub y bajo acoplamiento
Los motores de emparejamiento, las comprobaciones de riesgo y los publicadores de datos de mercado no deberían llamarse directamente entre sí en una gran bola de barro. Un bus de publicación/suscripción permite que el motor de emparejamiento emita fills mientras los servicios río abajo se suscriben sin conocer los detalles de implementación de los servicios río arriba — pero aun así hay que elegir las garantías de entrega (al menos una vez frente a exactamente una vez) y la retención para poder repetir el flujo (replay).
Cortacircuitos y mamparos (bulkheads)
Un cortacircuitos (circuit breaker) deja de llamar a una dependencia enferma tras fallos repetidos, dándole tiempo para recuperarse y protegiendo tus pools de hilos. Los mamparos (bulkheads) aíslan los pools de recursos para que un trabajo de analítica descontrolado no pueda dejar sin recursos al envío de órdenes.
Máquinas de estados e idempotencia
Las órdenes y las transferencias tienen ciclos de vida bien definidos. Codifica las transiciones permitidas en una máquina de estados finita para que los saltos no válidos sean imposibles. Combina eso con claves de idempotencia en las solicitudes del cliente para que los reintentos de red no puedan crear órdenes activas duplicadas.
Motores de emparejamiento: prioridad precio-tiempo
Los mercados centralizados emparejan las órdenes entrantes con la liquidez en espera según la prioridad precio-tiempo. Los motores de emparejamiento en cadena (como muchos diseños de DEX en Layer 1) deben ser deterministas: cada validador reejecuta la misma secuencia y llega a un estado idéntico — GaiaEx hereda este modelo de las reglas de Hyperliquid.
Adopción pragmática
No copies mecánicamente todos los patrones el primer día. Empieza con límites claros, registros estructurados y pruebas alrededor del movimiento de dinero. Añade un registro de eventos cuando aparezca dolor de reconciliación; añade cortacircuitos cuando las API externas empiecen a fallar de forma intermitente. Los patrones resuelven raspaduras reales, no imaginarias.