Dos motores de orquestación para banca: Temporal para sagas, Flowable para personas

Un mismo motor de orquestación no debería ocuparse a la vez de las transacciones entre microservicios y de los procesos que esperan semanas a que una persona apruebe algo. Esa es la tesis de un análisis de arquitectura para plataformas de banca central: partir el problema en dos, Temporal para las sagas de máquina y Flowable para los flujos con intervención humana, y asignar cada uno a los dominios de servicio que define BIAN.

El argumento de partida es que mezclar ambos perfiles degrada el sistema. Meter a un motor BPMN a ejecutar sagas de microservicios de baja latencia acaba inflando el estado en base de datos y dejando sin hilos a los workers. Al revés, un motor code-first gestionando tareas humanas que duran semanas esconde la visibilidad del negocio, deja las cadenas de aprobación grabadas en el código y complica la auditoría.

Quién orquesta cada dominio

La propuesta reparte responsabilidades según cuánto dura el estado, cuánto throughput exige el proceso y si hay una persona en medio. En pago (compensación automática, enrutado de mensajes ISO20022) manda Temporal con una saga de compensaciones, por debajo de 200 ms y consistencia eventual determinista. En Position Keeping, Temporal ejecuta una actividad atómica en dos fases, con menos de 50 ms y consistencia fuerte.

En el otro extremo, la originación de préstamos al consumo va entera sobre Flowable con tareas de usuario BPMN 2.0 y plazos de días a semanas. La evaluación de crédito queda híbrida: Flowable dirige y Temporal ejecuta, en segundos si el scoring es automático y en horas si toca underwriting manual. Lo mismo en el alta de cliente con verificación KYC y screening de sanciones, donde Flowable marca las puertas de etapa y Temporal lanza las comprobaciones, de minutos a días.

El encaje técnico es un bus de eventos o gRPC asíncrono entre los dos planos: arriba Flowable, abajo Temporal, y de ahí a los motores de pago, la API del libro mayor y el motor de screening.

Qué aporta Temporal

Temporal persiste la traza completa de ejecución de la aplicación, así que el código sobrevive a caídas del proceso, particiones de red y caídas de sistemas downstream. En el libro mayor no vale un ACID distribuido por contención de bloqueos: se usa el patrón saga con acciones compensatorias registradas por cada paso hacia adelante. El ejemplo que acompaña al texto es un workflow en Go que reserva fondos en la cuenta origen, registra la compensación que anula esa reserva y lanza el screening de sanciones. Si algo falla, las compensaciones se ejecutan en orden inverso desde un contexto desconectado, con timeout de 5 segundos por actividad, cinco intentos y retroceso exponencial con coeficiente 2.

Lo que no trae el análisis son medidas. Los objetivos de latencia que aparecen, esos 200 ms y 50 ms, son del diseño, no el resultado de un banco en producción. El marco en el que se encuadra todo se presenta como estándar, sin referencias externas que lo respalden. Queda por ver si alguna entidad publica cifras reales de un despliegue así y si el coste de operar dos motores en paralelo compensa la separación.