Coordination

La pregunta arquitectónica

Coordination examina cómo múltiples participantes alinean acciones, estados y fallos para producir un resultado conjunto. Incluye decisiones sobre orden, acuerdos, invariantes, progreso, concurrencia, recuperación y autoridad para decidir. No se limita a enviar información ni presupone distribución.

Malone y Crowston estudian la coordinación como gestión de dependencias entre actividades. Esa perspectiva ayuda a mirar requisitos compartidos antes de elegir un mecanismo: reservar un recurso, esperar un resultado o resolver una disputa son problemas diferentes. El uso arquitectónico de este documento aplica esa idea a unidades de software. Malone y Crowston, 1994.

Es una dimensión de architecture-decision-axes, no un estilo, patrón, tecnología ni nivel de madurez. monolith, modular-monolith, service-based-architecture, service-oriented-architecture y microservices pueden combinar coordinación local y distribuida. El nombre del perfil no decide todos sus acuerdos.

Communication no define la política

communication describe cómo intercambian información los participantes. Orders → PaymentRequested → Payments identifica un mensaje y su destinatario. No determina quién confirma el pedido, qué ocurre si el pago tiene éxito pero Inventory rechaza la reserva, quién reintenta, quién compensa ni cuándo termina el proceso.

Pregunta	Dimensión
¿Cómo llega PaymentRequested?	communication
¿Quién decide confirmar Orders?	Coordination
¿Quién modifica la autorización?	data-ownership
¿Qué protege Orders de Payments lento?	isolation

El mecanismo de comunicación y la política de coordinación son decisiones distintas. Un canal durable puede conservar una solicitud; no deduce qué hacer con una autorización tardía. Las reglas pueden estar en una función local, un coordinador explícito o varias máquinas de estados.

Place Order como resultado conjunto

Nuestro ejemplo ilustrativo asigna responsabilidades a Orders, Payments, Inventory y Shipping. Elegimos una política: crear un pedido pendiente, reservar inventario, autorizar pago, confirmar el pedido e iniciar el envío. No es una secuencia universal; permite precisar compromisos.

Orders: crear pedido pendiente
  → Inventory: reservar unidades
  → Payments: autorizar importe
  → Orders: confirmar con evidencia suficiente
  → Shipping: iniciar envío

La autoridad del proceso debe distinguir aceptación de finalización. En este ejemplo, Place Order termina cuando el pedido confirmado tiene una solicitud de envío aceptada; entregar el paquete es otro resultado. Si Shipping no acepta, existe trabajo pendiente, aunque reservar y autorizar hayan funcionado.

Se necesita identificar el pedido, registrar avances y establecer quién retoma trabajo tras una interrupción. Un responsable puede ser OrderWorkflow sin que deba ejecutar cada operación. Debe conocer la decisión pendiente y su evidencia, no inventar estados de los participantes.

Coordinación dentro de una frontera local

Hay coordinación dentro de un proceso, un módulo y una base de datos. Un servicio de aplicación puede ordenar validaciones y cambios mediante contratos locales. Las actividades no dejan de depender unas de otras porque compartan memoria.

Una frontera transaccional única puede coordinar varias escrituras: crear Orders, reservar stock y registrar un estado local de pago, si esas operaciones participan realmente en la misma transacción. Atomicidad permite confirmar o abortar ese conjunto. Las garantías de visibilidad y concurrencia dependen además del aislamiento transaccional y del modelo elegido.

Una autorización realizada por un proveedor externo de Payments queda fuera de ese rollback local. Registrar su resultado en una tabla no incorpora retrospectivamente el efecto externo a la transacción. Harán falta consulta, conciliación, cancelación u otra respuesta del dominio si el commit local falla.

La transacción es un mecanismo posible, no la definición de Coordination. Incluso con commit atómico hay decisiones sobre qué validar primero, qué mensajes producir y qué representa éxito. Mantener una transacción abierta mientras se espera una red puede prolongar bloqueos sin resolver esa frontera.

Cuando los participantes se distribuyen

Separar procesos, redes, autoridades de datos o dominios de fallo introduce resultados parciales y recuperación independiente. Orders puede interrumpirse después de que Payments autorice; también puede recibir tarde una respuesta válida. La falta de respuesta no permite distinguir automáticamente rechazo, pérdida del mensaje o éxito remoto.

Un timeout limita una espera, no certifica que Payments no actuó. retry requiere una política para errores, presupuesto e incertidumbre. idempotency permite controlar efectos repetidos bajo un contrato; no elimina todos los conflictos entre operaciones diferentes.

La coordinación necesita decidir cómo recuperar evidencia y qué acciones siguen siendo legales. Por ejemplo, consultar una autorización mediante su identidad antes de repetirla evita tratar todo silencio como fracaso. Una recuperación concurrente debe comprobar que el pedido no fue confirmado o cancelado por otro actor.

Atomic Commit, Saga y TCC tienen alcances propios

atomic-commit aborda un resultado común de commit o abort entre participantes de una transacción. two-phase-commit es un protocolo particular para obtenerlo; puede bloquear ante ciertos fallos. Es un problema específico dentro de coordinación distribuida, no su definición. Gray y Lamport, Consensus on Transaction Commit.

saga-pattern organiza transacciones locales con acciones de avance y compensación cuando no se usa una transacción global. Compensar una reserva ya confirmada es una nueva acción de negocio; no borra el tiempo ni debe sobrescribir cambios concurrentes legítimos. Saga no proporciona automáticamente aislamiento global ni garantiza cualquier propiedad denominada «consistencia». García-Molina y Salem, Sagas, 1987.

try-confirm-cancel exige contratos para intentar reservar, confirmar o cancelar. Cambia obligaciones de los participantes y la semántica de recursos retenidos. La documentación de Oracle muestra una realización basada en reservas; sus endpoints concretos no definen este eje. Oracle, modelo TCC.

Alternativa	Compromiso que debe examinarse
two-phase-commit	Acuerdo atómico y espera ante fallos.
saga-pattern	Pasos locales y compensación de negocio.
try-confirm-cancel	Reservas y decisión confirm/cancel.

La selección depende de invariantes, contratos disponibles, bloqueos o reservas, latencia, recuperación y costo operativo. No hay una clasificación universal de superioridad. Tampoco todo workflow distribuido exige una transacción distribuida: notificar Shipping de un pedido confirmado puede admitir progreso diferido.

Orchestration y Choreography

Orchestration hace explícito un participante que conoce el proceso y dirige sus transiciones. OrderWorkflow solicita reservar, autorizar y enviar; mantiene evidencia para decidir el siguiente paso. Enterprise Integration Patterns describe Process Manager como responsable del estado de una secuencia y de elegir el siguiente paso a partir de resultados. Process Manager.

Choreography distribuye la política entre participantes que reaccionan a hechos o señales. OrderPlaced puede activar Inventory y Payments; otro participante decide con qué hechos puede confirmar. No existe necesariamente un único controlador de todas las transiciones, pero sí reglas de correlación, orden, recuperación y finalización. Azure Architecture Center, enfoques de Saga.

Orchestration no equivale a comunicación síncrona: un coordinador puede emitir mensajes y continuar después. Choreography no equivale simplemente a async: una llamada asíncrona dirigida por OrderWorkflow sigue teniendo control explícito. «Usamos eventos» tampoco prueba ausencia de coordinación ni bajo coupling. event-driven-architecture muestra variantes coreografiadas y orquestadas: propagar hechos no decide quién confirma el pedido ni cómo recuperar un resultado parcial.

Un coordinador puede mejorar visibilidad de extremo a extremo y acumular conocimiento de negocio o convertirse en cuello de botella. Una política distribuida puede conservar autonomía y hacer más difícil reconstruir el flujo, seguir fallos y evolucionar contratos. Ninguna opción elimina el costo; lo distribuyen de distinta manera.

mediator-pattern organiza colaboración entre objetos. Su alcance no es automáticamente un proceso durable entre servicios. Un handler de MediatR puede formar parte de una implementación, pero su existencia no demuestra recuperación de workflows, responsabilidad por progreso ni coordinación de transacciones remotas.

Orden y concurrencia

Authorize payment antes de Capture payment es una restricción del ejemplo. No obliga a ordenar totalmente todos los pedidos del sistema. Puede bastar orden parcial entre pasos o por entidad; otras actividades, como preparar información de envío, pueden ejecutarse en paralelo.

Dos actores podrían reservar las últimas unidades simultáneamente. Inventory debe decidir cómo protege su invariante: serialización, validación optimista, detección de conflictos o reservas son alternativas según su modelo. Distribuir solicitudes no sustituye el control local que impide aceptar dos usos incompatibles.

Recuperar el mismo proceso desde dos workers plantea otra concurrencia. Registrar una decisión con una versión esperada puede evitar transiciones incompatibles; identificar comandos repetidos evita duplicar efectos. Estas son decisiones que un mecanismo debe hacer efectivas, no garantías implícitas del diagrama.

Coordination frente a Consistency y autoridad

Consistency describe propiedades o expectativas del estado; Coordination describe cómo se alinean actividades para alcanzar o mantener resultados. Un modelo de consistencia puede requerir acuerdos concretos, pero los términos no son sinónimos.

El invariante stock disponible no negativo puede quedar íntegramente dentro de Inventory. «Confirmar solo con reserva y autorización válidas» atraviesa autoridades y requiere coordinación o una reformulación explícita del resultado. Eso no implica que todos los datos deban cambiar atómicamente ni que puedan aceptarse estados intermedios sin restricciones.

data-ownership determina quién define y cambia el estado autoritativo. OrderWorkflow puede ser responsable del progreso y de su propio registro sin apropiarse del saldo, stock o shipment. Centralizar visibilidad del proceso no autoriza escrituras directas sobre tablas privadas.

Consecuencias y evidencia

Mayor isolation puede impedir depender de memoria, locks o transacciones compartidos; coordinar exige entonces contratos y recuperación entre fronteras. Compartir recursos puede simplificar acuerdos locales y ampliar el alcance de un fallo. La interacción necesita justificar ambas decisiones.

operability importa para identificar procesos detenidos, responsables y decisiones pendientes. cost-efficiency exige contar mensajes, estado de recuperación y trabajo humano, además del camino exitoso. Un resultado aparente con compensaciones ocultas no demuestra que el diseño sea barato de operar.

Revisar Place Order con autorización tardía, stock agotado y recuperación simultánea. Preguntar qué evidencia permite confirmar, qué participante decide y cómo se detecta finalización. Sin esas respuestas, ni un coordinator central ni una choreography documentada en flechas prueban una política completa.