Coreografía vs orquestación
«¿Dónde están mis 100 €?»
Jueves, 18:40. Ana ha enviado 100 € a Luis, que esta vez tiene la cuenta en otro banco. La app dijo «en curso» hace tres horas. Luis no ha recibido nada y Ana no puede gastar esos 100 €. Llama al banco.
La persona que la atiende abre el panel de operaciones y busca la transferencia. Y aquí empieza el problema: ¿dónde mira?
Una transferencia a otro banco no es como la interna del episodio 1, donde Cuentas movía el dinero en una sola transacción. Aquí hay varios pasos, y entre ellos pasan segundos, minutos u horas. Cuentasver en el mapa retiene el importe (sigue en la cuenta de Ana, pero no puede gastarlo). Transferenciasver en el mapa lo envía al banco de Luis. Si el banco lo acepta, Cuentas convierte la retención en un cargo; si lo rechaza, libera la retención. Y al final, Notificaciones avisa a Ana.
Hay dos formas de encadenar esos pasos. En la coreografía, cada servicio escucha el evento del anterior, hace lo suyo y publica el siguiente; nadie dirige. En la orquestación, un servicio (aquí, Transferencias) pide cada paso y apunta en qué punto va. Las dos funcionan. La pregunta de este episodio es la de la persona del teléfono: ¿quién sabe cómo va la transferencia de Ana?
La misma transferencia, con y sin director
Cada vez que pulsas Enviar, Ana envía 100 € a Luis en los dos modelos. Mientras avanza, mira el recuadro ¿Cómo va? de cada panel: es lo que podría contestar la persona del teléfono. Cambia lo que hace el banco de Luis (aceptar, tardar, rechazar o no contestar nunca) y añade un paso nuevo al proceso.
Qué ha pasado
Un proceso largo no se hace en una transacción
Lo primero que tienen en común los dos modelos: Ana recibe «en curso» al instante y puede cerrar la app. No tendría sentido tenerla esperando a que conteste otro banco, que puede tardar horas. La transferencia pasa a ser un proceso con estados, y la consistencia entre Cuentas y el banco de Luis es eventual.
Tampoco se puede meter en una transacción de base de datos: el banco de Luis tiene su propia base de datos, en otra empresa. Lo que se hace es encadenar pasos locales (retener, enviar, cargar) y, si algo falla después de un paso, compensarlo con otro paso que lo deshaga (liberar la retención). A eso se le llama saga, y es el tema del episodio 4. Aquí nos interesa quién la dirige.
Coreografía: cada uno sabe su parte
En la coreografía, el flujo no está escrito en ningún sitio. Sale de las suscripciones: Cuentas escucha TransferenciaIniciada y retiene; Transferencias escucha RetenciónAplicada y envía; Cuentas escucha TransferenciaCompletada y carga. Cada servicio solo conoce el evento que le toca y el que publica.
Es lo que el episodio 1 defendía para los efectos secundarios, llevado a todo el proceso. Tiene las mismas ventajas: nadie depende de que otro esté en pie en ese momento, y añadir un interesado al final (Reporting, Fidelización) no toca a nadie.
Pero mira el recuadro «¿Cómo va?».probar en el laboratorio Transferencias sabe que la envió; Cuentas, que hay una retención activa; Notificaciones, nada. El estado de la transferencia de Ana no existe en ningún sitio: hay que reconstruirlo juntando lo que sabe cada servicio. Para la persona del teléfono, eso significa abrir tres paneles.
Orquestación: alguien lleva la cuenta
En la orquestación, Transferencias ejecuta el proceso como una función: pide a Cuentas que retenga, envía al banco, pide a Cuentas que cargue o que libere. Después de cada paso, guarda en qué punto va. Si alguien pregunta, hay una respuesta: «ENVIADA, esperando al banco de Luis desde las 15:42».
Fíjate en que los pasos siguen siendo comandos a otros servicios, y el resultado final sigue siendo un evento (TransferenciaCompletada) para quien le interese. Orquestar no significa dejar los eventos, sino que el proceso tiene dueño.
Lo que no pasa
Ahora haz que el banco de Luis no conteste nunca.probar en el laboratorio Es la llamada de Ana.
En coreografía no pasa nada, literalmente. No hay ningún error en ningún registro: cada servicio hizo su parte bien. Los 100 € de Ana se quedan retenidos y nadie se entera hasta que ella llama. Para detectar que algo no ha ocurrido hace falta alguien que sepa qué debería ocurrir y cuándo. En coreografía, ese alguien no existe.
En orquestación, Transferencias tenía un temporizador. Al agotarse, sabe exactamente dónde se ha quedado el proceso: lo marca «en revisión», avisa a operaciones y le dice a Ana que va con retraso. Qué hacer a continuación (preguntar al banco, reintentar el envío sin mandar el dinero dos veces) es el tema del episodio 4.
Se puede añadir un temporizador a la coreografía: un servicio que escuche TransferenciaIniciada, apunte la hora y, si no ve TransferenciaCompletada ni TransferenciaRechazada a tiempo, dé la alarma. Pero ese servicio tiene que conocer el proceso entero y guardar su estado… y eso es un orquestador que no se atreve a decir su nombre. A veces se le llama process manager.
Deshacer: ¿dónde está la compensación?
Si el banco de Luis rechaza la transferencia, los dos modelos liberan la retención.probar en el laboratorio La diferencia está en dónde vive esa decisión. En orquestación, es una línea de la función: else await cuentas.liberar(orden). En coreografía, es un suscriptor de Cuentas que escucha TransferenciaRechazada. Para saber qué pasa si el banco rechaza, hay que buscar quién escucha ese evento, en el código de otro equipo.
Cambiar el proceso
Llega un requisito nuevo: antes de enviar dinero fuera, Antifraudever en el mapa tiene que verificar la cuenta de destino. Pulsa «Nuevo paso».probar en el laboratorio
En orquestación es una línea nueva en transferirFuera, entre retener y enviar. En coreografía cambian dos servicios: Antifraude se suscribe a RetenciónAplicada y publica DestinoVerificado, y Transferencias tiene que dejar de escuchar RetenciónAplicada para escuchar DestinoVerificado. Si el equipo de Transferencias no se entera de lo segundo, el dinero sale antes de que Antifraude termine de verificar, y nadie lo nota hasta que pasa algo.
Este es el contrapunto del episodio 1. Añadir un interesado al final favorece a los eventos: nadie cambia. Insertar un paso en medio de un proceso favorece a la orquestación: el orden está escrito en un sitio.
Lo que cuesta orquestar
- Transferencias sabe más. Conoce a Cuentas, a Antifraude y al banco de Luis, y en qué orden llamarlos. Si el orquestador empieza a tomar decisiones que son de otros (calcular comisiones, decidir el riesgo), acaba siendo un servicio que lo hace todo y unos servicios alrededor que no hacen nada.
- Tiene que guardar su estado. Si Transferencias se reinicia a mitad de una transferencia, tiene que retomarla donde estaba. La función del ejemplo es una simplificación: en la vida real el estado va a una base de datos, o se usa un motor que lo hace por ti (ver más abajo).
- Un punto por el que pasa todo. Si Transferencias cae, ninguna transferencia avanza. Con coreografía, cada paso depende solo del broker y de su servicio.
Criterio
No es una decisión para todo el sistema, sino para cada proceso. Recorre estas preguntas:
-
¿Alguien va a preguntar «¿cómo va?» o «¿por qué se ha parado?»Clientes, operaciones, auditoría. En un banco, casi siempre.orquestación
-
¿Hay pasos que dependen del resultado de otros, con compensaciones o plazos?Si el banco rechaza, liberar; si no contesta en un plazo, revisar.orquestación
-
¿Son reacciones independientes a un mismo hecho, que pueden ir en cualquier orden?Avisar, anotar en el extracto, sumar puntos.coreografía
- Proceso corto, de dos o tres pasos, que no va a cambiar mucho: la coreografía es más simple. Vigila que no crezca.
Y lo normal es mezclar. En BCPS Bank:
| Proceso | Modelo | Por qué |
|---|---|---|
| Transferencia a otro banco: retener, enviar, cargar o liberar | orquestación | Pasos en orden, compensaciones, plazos, y clientes que preguntan. |
Después de TransferenciaCompletada: avisar, extracto, puntos | coreografía | Reacciones independientes; Transferencias no debería saber quién hay. |
| Alta de cliente: verificar identidad, abrir cuenta, emitir tarjeta | orquestación | Si falla la verificación, no se abre nada; el cliente pregunta «¿por qué tarda?». |
Después de CuentaAbierta: Tarjetas prepara la tarjeta, Notificaciones da la bienvenida | coreografía | Cada contexto reacciona a su ritmo. |
Una señal de que una coreografía se te ha ido de las manos: para explicar el proceso a alguien nuevo tienes que dibujar un diagrama en la pizarra, porque no está escrito en ningún sitio. Y una de que el orquestador se ha comido a los demás: los otros servicios son tablas con una API delante.
En el mundo real
Guardar el estado de un orquestador a mano (en qué paso va, qué temporizadores tiene, qué hacer si se reinicia) es más difícil de lo que parece. Por eso existen motores de flujos que lo hacen por ti: Temporal (y Cadence, del que sale), AWS Step Functions, Azure Durable Functions, Camunda o Netflix Conductor. En Temporal, por ejemplo, escribes transferirFuera casi como en la simulación y el motor se encarga de que sobreviva a reinicios, con temporizadores de horas o días.
Para la coreografía basta un broker. Lo difícil ahí es la visibilidad: se suele resolver con un identificador de correlación que viaja en todos los eventos de una misma transferencia y con trazas distribuidas (OpenTelemetry), para poder reconstruir después qué pasó.
La banca real tiene de todo. Las transferencias entre bancos pasan por sistemas de compensación (en Europa, por ejemplo, las transferencias SEPA) que responden de forma asíncrona y, a veces, tarde. Por eso tu banco te enseña estados como «en proceso» o «pendiente»: alguien, en algún sitio, lleva la cuenta.
Siguiente episodio
Hemos dado por hecho que cada paso se hace una vez y que cada evento llega. En la vida real, Transferencias se puede caer entre guardar el estado y publicar el evento, el banco de Luis puede recibir el envío dos veces, y Ana puede pulsar «Reintentar». ¿Te acuerdas de la transferencia duplicada del episodio 1?
Siguiente · Episodio 4 Cuando algo falla a mitad Saga, Outbox e idempotencia: las tres piezas para que una transferencia a otro banco termine bien, o termine deshecha, pase lo que pase.