🎯
PRINCIPIO FUNDAMENTAL — UN ÚNICO COORDINADOR EXPLÍCITO
El orquestador sabe qué paso sigue, qué debe compensarse si falla, y persiste su propio estado. Los servicios participantes sólo ejecutan comandos — no saben que forman parte de una Saga.
El orquestador centraliza la lógica del flujo de negocio. El estado global de la transacción larga vive en un único lugar — una entidad de base de datos con su máquina de estados. Los servicios participantes son ejecutores puros: reciben un comando, realizan su trabajo local y responden con éxito o fallo.
Relación orquestador ↔ servicios participantes (pedido de e-commerce)
📦
Inventory Service
reserveStock / releaseStock
→ ReserveStock
← StockReserved
→ ReleaseStock (comp)
💳
Payment Service
processPayment / refundPayment
→ ProcessPayment
← PaymentSucceeded
← PaymentFailed
→ RefundPayment (comp)
🎯
ORDER SAGA
ORCHESTRATOR
Proceso durable
ESTADO PERSISTIDO
saga_id · step · status
Conoce el estado global.
Decide qué compensar.
🛒
Order Service
confirmOrder / cancelOrder
→ ConfirmOrder
← OrderConfirmed
→ CancelOrder (comp)
🚚
Shipping Service
createShipment / cancelShipment
→ CreateShipment
← ShipmentCreated
→ CancelShipment (comp)
🔑 Los servicios no saben entre sí que son parte de una Saga. Sólo ven comandos del orquestador y responden. Esta separación es la clave: podés añadir o quitar pasos sin tocar los servicios participantes.
Estados del flujo — happy path y compensación
HAPPY PATH →
⏳
PENDING
inicio
→
📦
RESERVING
stock
→
💳
PAYING
pago
→
🚚
SHIPPING
envío
→
✅
COMPLETED
final OK
COMPENSACIÓN ← (cuando falla el pago)
❌
PAY_FAILED
pago rechazado
→
↩
RELEASING
comp. stock
→
↩
CANCELLING
comp. orden
→
🚫
CANCELLED
final KO
📌 El orquestador persiste cada transición de estado antes de enviar el siguiente comando. Si el orquestador cae y reinicia, sabe exactamente en qué paso estaba y puede reanudar desde ahí — esto lo convierte en un proceso durable. Herramientas como Temporal.io, AWS Step Functions o Conductor gestionan esto por vos.
Servicio no responde (timeout)
Crítico
Reintenta N veces con backoff exponencial. Si supera el límite, activa el path de compensación desde el paso actual hacia atrás.
Retry + Compensate
Servicio responde con error de negocio
Crítico
El error de negocio (PaymentFailed) es una respuesta válida — no se reintenta. Se activa inmediatamente el path de compensación para los pasos ya completados.
Compensate only
El orquestador cae a mitad del flujo
Alto
El estado persistido en BD permite recuperar la Saga desde el último estado consistente al reiniciar. El proceso durable retoma desde ahí.
Durable Process
Comando enviado pero respuesta perdida
Alto
El orquestador reenvía el comando (at-least-once). El servicio participante debe ser idempotente — procesar el mismo comando dos veces no produce efectos duplicados.
Idempotency Key
Compensación que falla a su vez
Medio
Reintento agresivo de la compensación (es crítico que se complete). Si no puede compensar automáticamente, escala a intervención manual — alertas y dead-letter queue.
Retry + Manual
Acción no compensable (email enviado)
Medio
La compensación es una acción correctiva, no un rollback real. Enviar un email de disculpa o una nota de crédito es la compensación — no se puede "desenviar" el primero.
Corrective Action
Visibilidad del flujo
distribuida El flujo emerge — no está en un solo lugar
centralizada El orquestador es el único lugar donde ver el estado
Acoplamiento
bajo Solo conocen el contrato de eventos
medio Los servicios son desacoplados entre sí pero dependen del orquestador
Complejidad del flujo
Simple, lineal (2-4 pasos)
maneja bien Flujos complejos con ramas, condiciones y reintentos
Debugging
difícil Hay que correlacionar logs de múltiples servicios
fácil El estado de la Saga es un registro con historial de pasos
Testing
Necesita integración para probar el flujo completo
testeable en unitario El orquestador es una clase con su lógica — se puede testear solo
Punto único de fallo
ninguno No hay nodo central
el orquestador Debe ser altamente disponible y durable
🎯
Elige orquestación cuando…
El flujo tiene más de 4-5 pasos, hay condiciones de ramificación (si el stock es bajo, usa proveedor B), necesitás visibilidad del estado en tiempo real, o el negocio exige auditoría detallada. La ganancia en observabilidad y control compensa la mayor complejidad del orquestador.
⚡
Herramientas para el orquestador
Podés implementarlo a mano (entidad Saga en tu BD) o usar herramientas especializadas: Temporal.io (workflows durables), AWS Step Functions (serverless), Conductor (Netflix OSS), o BPMN engines como Camunda. A mayor complejidad del flujo, más vale la inversión en infraestructura.