Diseñando para el Fallo: Arquitecturas de alta disponibilidad cuando el Time-Out es de 20 segundos

En el mundo de los pagos batch, una demora de 10 minutos es una molestia. En el ecosistema de los Pagos Inmediatos (como Bre-B o Pix), una latencia de 21 segundos es un fallo sistémico. Cuando la regulación exige liquidar en ventanas de segundos, la arquitectura de software deja de ser un diagrama estático para convertirse en una estrategia de supervivencia operativa.

La llegada de Bre-B a Colombia impone una métrica que muchos Core Bancarios tradicionales no están preparados para manejar: un tiempo máximo de abono de 20 segundos y un hard time-out de 45 segundos para todo el ciclo de la operación. Si el sistema no responde en esa ventana, la transacción no entra en una cola de espera; simplemente deja de existir.

Diseñar para este escenario requiere un cambio de mentalidad: dejar de diseñar para el “camino feliz” (happy path) y empezar a diseñar para el fallo. ¿Qué pasa cuando el Core no responde? ¿Qué pasa si el enlace se cae en el segundo 19? Aquí analizamos las estrategias de arquitectura para sobrevivir al cronómetro.

1. El enemigo es el acoplamiento síncrono

La mayoría de los sistemas heredados (legacy) operan de manera síncrona: el canal digital llama al bus, el bus llama al Core, el Core bloquea una fila en la base de datos, actualiza el saldo y responde. Si el Core tarda 25 segundos en responder debido a un proceso de cierre diario, la transacción falla.

La solución: Desacoplamiento y Stand-In Processing (STIP)

Para cumplir con la ventana de los 20 segundos, la arquitectura debe desacoplar la autorización de la contabilización final.

• Capas de Orquestación (Payment Hubs): Se implementa una capa intermedia (como Brizmo) que gestiona la mensajería ISO 20022 y las reglas de negocio.
• Stand-In Processing: Si el Core principal no responde en milisegundos, el orquestador debe tener la autonomía para autorizar la transacción basándose en una “copia sombra” de los saldos o reglas pre-aprobadas, garantizando la inmediatez al usuario y sincronizando con el Core a posteriori (asincronía).

2. Idempotencia: La red de seguridad contra el “Doble Gasto”

En sistemas distribuidos con time-outs estrictos, el error más peligroso no es rechazar una transacción válida, sino procesarla dos veces. Si un pago en Bre-B alcanza el time-out de 45 segundos, el sistema iniciador probablemente enviará un reintento automático.

Sin una arquitectura idempotente, el sistema receptor podría procesar el primer intento (que llegó tarde) y el segundo (el reintento), duplicando el débito al usuario.

• Estrategia técnica: Los sistemas deben utilizar identificadores únicos de transacción (como el End-to-End ID en ISO 20022) para reconocer solicitudes repetidas. Si el sistema recibe un ID que ya procesó, debe devolver el resultado original almacenado en caché, sin volver a ejecutar la lógica de movimiento de dinero.

3. Circuit Breakers y Failover en Milisegundos

Cuando un componente falla en una arquitectura de microservicios, el riesgo es que el fallo se propague en cascada, saturando los recursos de todo el banco.

• Patrón Circuit Breaker: Si el servicio de prevención de fraude tarda más de 300ms en responder consistentemente, el sistema debe “abrir el circuito” y fallar rápido o derivar a un mecanismo de validación simplificado, en lugar de mantener el hilo de ejecución abierto hasta consumir los 20 segundos.
• Observabilidad en tiempo real: No basta con monitorear si el servidor está “arriba”. Herramientas como SmartAcceptance son críticas para correlacionar latencias y tasas de rechazo en tiempo real, permitiendo a los equipos de SRE (Site Reliability Engineering) reaccionar antes de que se violen los SLAs regulatorios.

4. La Estrategia de Kuvasz: Orquestación Inteligente

En Kuvasz Solutions, entendemos que modernizar no siempre significa reemplazar el Core (“Rip and Replace”), lo cual es costoso y arriesgado. Nuestra aproximación es la modernización progresiva a través de la orquestación:

• Brizmo como escudo: Nuestra plataforma actúa como un amortiguador entre la velocidad de los rieles inmediatos (Bre-B, Transfiya) y los tiempos del Core bancario. Gestiona la resolución de llaves, la validación ISO 20022 y la lógica de time-outs, protegiendo al Core de picos de tráfico.
• TestRFlow para el caos: No se puede salir a producción esperando que el time-out nunca ocurra. Utilizamos TestRFlow para automatizar pruebas de estrés y simular escenarios de borde (latencia alta, pérdida de paquetes), asegurando que la arquitectura se recupere correctamente cuando el reloj marque el segundo 21.

Conclusión

En la era de los pagos inmediatos, la alta disponibilidad no es un requisito no funcional; es la funcionalidad principal. Diseñar para el fallo significa asumir que la red será lenta y que los servicios caerán, y construir una arquitectura lo suficientemente inteligente para que, incluso en el peor día del sistema, el usuario reciba su confirmación en menos de 20 segundos.

En Kuvasz, llevamos más de 17 años asegurando que, sin importar dónde residan sus servidores, el pago siempre llegue a tiempo.

---

Fuentes: Tiempos Bre-B; Arquitectura desacoplada y orquestación; Idempotencia y doble gasto; Capacidades de Kuvasz (Brizmo, TestRFlow, SmartAcceptance).