Volver al blog
• 6 min de lectura

Orquestación vs Coreografía en sistemas distribuidos: cómo elegir sin sufrir

Orquestación vs coreografía no es una pelea filosófica, es una decisión de operabilidad y control de fallas. Si tu proceso tiene alto costo de error, muchas ramas o necesita auditoría: orquesta. Si tu sistema vive de extensiones por eventos y el flujo es simple: coreografía.

Arquitectura Coreografía Orquestación
Orquestación vs Coreografía en sistemas distribuidos: cómo elegir sin sufrir
Foto por Lucas Law

Cuando un sistema crece, tarde o temprano terminas coordinando pasos entre servicios: “crear orden”, “reservar inventario”, “cobrar”, “notificar”, “emitir factura”… y de pronto aparece la pregunta inevitable:

¿lo coordinamos con un orquestador central o dejamos que los servicios se coordinen por eventos?

Eso es Orquestación vs Coreografía. No hay ganador absoluto. Hay trade-offs muy reales: complejidad operativa, visibilidad, acoplamiento, latencia, y sobre todo: cómo se recupera el sistema cuando algo falla.

Definiciones sin humo

Coreografía

Cada servicio reacciona a eventos. No hay un “director”. La coordinación emerge del flujo de eventos.

  • Order Service publica OrderCreated
  • Inventory Service escucha y publica InventoryReserved o InventoryRejected
  • Payments Service escucha InventoryReserved y publica PaymentAuthorized o PaymentFailed
  • Shipping escucha PaymentAuthorized…

La lógica del flujo está distribuida.

Orquestación

Hay un orquestador explícito (un servicio o motor de workflows) que llama / manda comandos a otros servicios y decide qué sigue.

  • Orchestrator: “Reserva inventario → si ok, autoriza pago → si ok, confirma orden → si falla, compensa”
  • Los servicios hacen su trabajo y responden.

La lógica del flujo está centralizada.

La pregunta correcta no es “cuál es mejor”

La pregunta correcta es:

¿Dónde quieres que viva la complejidad: en el flujo distribuido (coreografía) o en un punto central (orquestación)?

Y luego: ¿qué necesita tu operación para dormir en paz?

Comparación práctica

Coreografía brilla cuando…

  • El flujo es simple y relativamente lineal.
  • Quieres bajo acoplamiento y alta extensibilidad.
  • Vas a agregar “listeners” nuevos con el tiempo (ej: antifraude, analítica, notificaciones).
  • Aceptas que el “mapa mental” del proceso vive repartido.

Ventajas

  • Menos dependencia en un componente central.
  • Fácil agregar nuevos consumidores (pub/sub).
  • Escala bien organizacionalmente: equipos autónomos.

Costos

  • Difícil ver el “estado de la saga” sin herramientas extra.
  • Debug complejo: “¿por qué esta orden no avanzó?”
  • Riesgo de flujos implícitos: nadie sabe quién depende de qué.
  • Compensaciones distribuidas: cada servicio decide, y eso se vuelve una telaraña.

Orquestación brilla cuando…

  • El proceso es crítico, largo o con muchas ramas.
  • Necesitas visibilidad: estado, tiempos, reintentos, auditoría.
  • Las compensaciones son delicadas (dinero, inventario, cumplimiento).
  • Quieres gobernanza del proceso: cambios controlados.

Ventajas

  • “Single place to reason”: el flujo es legible.
  • Reintentos/timeout/compensaciones más consistentes.
  • Observabilidad natural: sabes en qué paso va.
  • Menos coreografía accidental (menos “spaghetti de eventos”).

Costos

  • El orquestador puede volverse “god service” si no lo cuidas.
  • Puede aumentar acoplamiento si orquesta con conocimiento de detalles internos.
  • Es un componente más que operar y escalar.

Regla de oro (la que más sirve en producción)

  • Eventos para “hechos” (facts): algo ya pasó (PaymentAuthorized, OrderShipped).
  • Comandos para “intenciones” (commands): haz que pase (AuthorizePayment, ReserveInventory).

En la práctica:

  • Coreografía: predomina “facts → reactions”.
  • Orquestación: predomina “commands → next step”.

Ejemplo de negocio: Checkout (con fallas reales)

Coreografía (evento-céntrica)

  1. OrderCreated
  2. Inventory intenta reservar → publica InventoryReserved o InventoryRejected
  3. Payments escucha InventoryReserved → intenta autorizar → publica PaymentAuthorized o PaymentFailed
  4. Order escucha esos resultados → decide OrderConfirmed o OrderCancelled

¿Dónde viven las reglas del flujo? En cada consumidor. Y cuando agregas una rama nueva (ej: 3DS, antifraude, límites), el flujo se vuelve más difícil de razonar.

Orquestación (workflow)

  1. Orchestrator recibe CreateOrder
  2. ReserveInventory
  3. AuthorizePayment
  4. ConfirmOrder
  5. Si falla pago: ReleaseInventory + CancelOrder

¿Dónde viven las reglas del flujo? En una máquina de estados explícita.

Compensaciones: donde se decide la arquitectura

Cuando hay fallas, tienes 3 caminos típicos:

  1. Compensación (deshacer): liberar inventario, revertir reserva, cancelar orden.
  2. Reintento (volver a intentar): si es transitorio.
  3. Intervención humana: cola de “requires review”.

Orquestación facilita implementar esto con consistencia. Coreografía lo puede hacer, pero tiende a dispersar la lógica y a complicar la trazabilidad.

Si tu dominio toca dinero, saldos, cumplimiento, normalmente te conviene que el flujo principal sea orquestado (al menos en los pasos críticos).

Observabilidad: el factor que casi nadie mide antes

Con coreografía, si no diseñas observabilidad desde el inicio, terminas con:

  • “Eventos publicados” ✅
  • “¿Y el proceso completo?” ❌

Con orquestación, puedes modelar:

  • estado de instancia (por orden)
  • paso actual
  • tiempo en cada paso
  • razón de fallo
  • número de reintentos

Heurística operativa:

  • Si tu equipo va a necesitar un “panel de sagas”, eso es una señal fuerte hacia orquestación (o hacia construir un agregador de estado para coreografía, que es… básicamente crear un pseudo-orquestador).

Cómo aterrizarlo sin casarte con un framework

Coreografía “bien”

  • Eventos inmutables y versionados.
  • Idempotencia por consumidor (dedupe por eventId).
  • Outbox + retry para publicar.
  • Correlation IDs (traceId, sagaId, orderId) en cada evento.
  • Un “process tracker” opcional que materializa estado (read model) para operar.

Orquestación “bien”

  • Orchestrator como máquina de estados (persistida).

  • Comandos idempotentes hacia servicios.

  • Timeouts y retries por paso.

  • Compensaciones como transiciones explícitas.

  • Evita que el orquestador sepa detalles internos:

  • habla en términos de capacidades (ReserveInventory) no de tablas/campos.

Tip clave: muchos orquestadores buenos no son “un motor gigante”; pueden ser un servicio simple con una tabla workflow_instance + workflow_step y un scheduler/worker.

Cómo elegir (matriz rápida)

Elige coreografía si:

  • Flujos cortos
  • Nuevos consumidores se agregan seguido
  • El costo de fallar es moderado
  • Puedes tolerar eventual consistency y debug más complejo

Elige orquestación si:

  • Flujos largos o con muchas ramas
  • Compensaciones importantes (dinero/inventario/cumplimiento)
  • Necesitas auditoría y visibilidad de proceso
  • Quieres una fuente única de verdad del estado del flujo

Elige híbrido (muy común) si:

  • Orquestas el “happy path” crítico (checkout, onboarding, settlement)
  • Publicas eventos de hechos para extensiones (notificaciones, antifraude, analytics)

Patrón híbrido recomendado (mi default en fintech)

  1. Orquestación para el flujo de negocio crítico (saga/workflow)
  2. Eventos para “hechos” que otros servicios puedan consumir sin acoplarse
  3. Outbox + idempotencia para no duplicar efectos
  4. Un read model de estado de proceso para soporte/operación

Con eso tienes:

  • control y trazabilidad (orquestación)
  • extensibilidad (eventos)

Cierre

Orquestación vs coreografía no es una pelea filosófica, es una decisión de operabilidad y control de fallas.

Si tu proceso tiene alto costo de error, muchas ramas o necesita auditoría: orquesta. Si tu sistema vive de extensiones por eventos y el flujo es simple: coreografía. Y si es fintech/cripto/pagos: normalmente híbrido es lo que te deja dormir.

Si quieres, en el siguiente post lo convierto en algo más “hands-on” para Java:

  • esquema de tablas para workflow + outbox,
  • diseño de eventos (versionado + correlation),
  • y un ejemplo de saga de checkout con compensaciones.