1. Introducción: coordinar muchos workflows

Descripción

Al terminar esta lección vas a poder explicar por qué un sistema de automatización con varios workflows es más que la suma de sus flujos, vas a conocer el sistema completo de Cumbre —cómo order-triage deja de ser un flujo solitario y pasa a coordinar a otros tres— y vas a tener claros los tres desastres específicos que aparecen cuando coordinas mal: las cascadas, la pérdida de orden y los efectos duplicados. También vas a recibir el mapa de las ocho lecciones de este módulo, que van del dibujo del sistema a una coordinación que sobrevive a que una pieza se caiga a la mitad.

Esto importa por una razón muy concreta que ya viviste si trabajaste alguna vez con más de un workflow: el momento en que un flujo llama a otro, ese otro tarda o falla, y de repente no sabes si el trabajo se hizo, se hizo a medias, o se hizo dos veces. Un solo workflow, por más complejo que sea, lo puedes tener entero en la cabeza. En cuanto son tres o cuatro llamándose entre sí, aparecen preguntas que ningún nodo individual contesta: ¿en qué orden corren?, ¿qué pasa con los otros dos si el primero falla?, ¿quién se entera de que uno quedó a medias? Este módulo es sobre esas preguntas.

Conexión con el módulo: esta lección es el planteo, no la solución. Aquí conoces el sistema de varios workflows sobre el que vas a trabajar las ocho lecciones, nombras los tres desastres de la coordinación, y recibes el mapa. La lección 2 te da las dos formas de coordinar —un director central que llama a todos (orquestación) o piezas que reaccionan a eventos sin jefe (coreografía)—. La lección 3 te enseña a dibujar el grafo de quién depende de quién. Las lecciones 4 y 5 atacan dos problemas mecánicos: repartir trabajo sin perder items (fan-out/fan-in) y qué hacer cuando los eventos llegan más rápido de lo que se procesan (orden y contrapresión). La lección 6 es la bisagra del módulo: el patrón outbox, la técnica que hace robusta toda la coordinación. La lección 7 lleva todo esto al terreno de los agentes que se delegan tareas entre sí. Y la lección 8 lo junta en un proyecto: tres workflows dependientes coordinados de forma que una caída a la mitad no duplique ni pierda nada.

Una nota de continuidad antes de empezar. Este módulo asume que ya traes tres cosas de los módulos anteriores, y las vas a usar todo el tiempo:

• La idempotencia (Módulo 2): sabes hacer que repetir un efecto —cobrar, crear un registro, mandar un correo— no lo duplique, usando una clave de idempotencia. Aquí esa herramienta deja de proteger un solo workflow y pasa a proteger la coordinación entre varios.
• Los contratos (Módulo 3): sabes que cuando un workflow llama a otro, ese "llamar" es una promesa con una forma de entrada y una forma de salida, validada en la frontera. Aquí esos contratos son las aristas del grafo que vas a dibujar.
• El modelo de datos (Módulo 4): tienes un run ledger —un registro durable de qué ejecuciones ya ocurrieron— y una tienda de deduplicación en Postgres. Aquí ese ledger deja de ser la memoria de un flujo y pasa a ser la memoria compartida de todo el sistema. Es la pieza que, al final, hace que la coordinación sea segura.

Si alguna de esas tres cosas la sientes floja, este es buen momento para repasarla. Todo lo que sigue se apoya en ellas.

De un workflow solitario a un sistema con varios flujos

En el Módulo 1 comparamos un workflow con un puente sobre un arroyo: lo construyes, lo cruzas una vez en la demo, y la pregunta seria no es "¿funciona?" sino "¿qué le pasa cuando la realidad lo golpea?". Vamos a estirar esa imagen, porque este módulo cambia la escala del problema.

Un solo puente lo entiendes completo. Sabes de dónde a dónde va, cuánto peso aguanta, qué pasa si llueve. Ahora imagina que en lugar de un puente tienes una pequeña red de caminos en un pueblo: un camino principal que se bifurca en tres, dos de esos tres se vuelven a juntar más adelante, y uno de ellos, en cierto tramo, depende de que un puente lejano esté abierto. Cada camino, por separado, lo entiendes. Pero el pueblo como sistema tiene propiedades que ningún camino individual tiene: hay embotellamientos donde dos caminos convergen, hay un punto donde si se cae un puente se quedan aislados tres barrios a la vez, y hay un orden en que conviene despejar la nieve para que no se tape todo.

Eso es exactamente lo que pasa cuando pasas de un workflow a un sistema de varios. Cada flujo, por separado, lo sabes construir —de eso trataron las guías de fundamentos—. Pero el sistema completo tiene comportamientos que emergen solo de cómo se conectan las piezas: cascadas de fallos, cuellos de botella, efectos que se disparan dos veces porque dos flujos hicieron lo mismo sin enterarse. Esos comportamientos no viven en ningún nodo. Viven en las conexiones. Y este módulo es sobre las conexiones.

Piénsalo así: hasta ahora aprendiste a que cada flujo tuyo sea correcto por dentro. Este módulo te enseña a que el sistema sea correcto, aunque cada flujo por separado ya lo sea. Son dos niveles distintos, y el segundo no sale gratis del primero.

El sistema de Cumbre: order-triage ya no está solo

Recordemos a Cumbre, la distribuidora mayorista de café y té que conociste en el Módulo 1. Su flujo central es order-triage: recibe cada pedido por un webhook, lo clasifica con un AI Agent y lo registra en el CRM. Hasta el Módulo 4, lo tratamos casi como si fuera un flujo solitario que hacía todo su trabajo de corrido.

La realidad de un negocio que crece es que un solo flujo termina siendo demasiado. order-triage no debería saber cómo se consulta la línea de crédito de un cliente, ni cómo se emite un reembolso en la pasarela de pago, ni cómo se descuenta inventario en el sistema de bodega. Cada una de esas cosas es su propio dominio, con sus propias reglas, y conviene que viva en su propio workflow —por las mismas razones de contratos que viste en el Módulo 3: se prueba aparte, se versiona aparte, se reutiliza—. Así que el sistema real de Cumbre, el que vas a coordinar en este módulo, se ve así:

                          order-triage
                     (Webhook → AI Agent → CRM)
                               │
          ┌────────────────────┼────────────────────┐
          ▼                    ▼                    ▼
    check-credit          issue-refund        inventory-sync
  (consulta el         (emite un reembolso   (descuenta el stock
   límite de crédito    en la pasarela)       en la bodega)
   del cliente)

Cuatro workflows. Uno que coordina —order-triage— y tres que hacen trabajo especializado:

Workflow	Qué hace	Qué tipo de operación es
order-triage	Recibe y clasifica el pedido, y decide qué más hay que hacer	Coordinador
check-credit	Consulta si el cliente tiene crédito disponible para este pedido	Lectura (no cambia nada)
issue-refund	Emite un reembolso en la pasarela de pago	Efecto: mueve dinero
inventory-sync	Descuenta del inventario las unidades del pedido	Efecto: cambia el stock

Guarda esa columna de la derecha, porque es la misma que organizó toda la guía. check-credit es una lectura: consultarla dos veces da el mismo resultado y no hace daño. issue-refund e inventory-sync son efectos: emitir dos reembolsos son dos reembolsos, descontar dos veces el stock deja la bodega mal contada. Toda la dificultad de coordinar estos cuatro flujos se concentra en no disparar esos dos efectos más veces de las debidas.

Un pedido de Cumbre sigue teniendo la misma forma que ya conoces, con su order_id como nombre de negocio del pedido:

{
  "event_id": "evt_8f2a91c4",
  "order_id": "ORD-2041",
  "customer_id": "CUST-118",
  "customer_name": "Luna Coffee",
  "amount": 2154.00,
  "currency": "MXN"
}

order_id va a ser la columna vertebral de todo este módulo. Cuando coordines cuatro workflows, la pregunta constante va a ser "¿este trabajo, para este order_id, ya se hizo?". Y la respuesta va a vivir en el ledger del Módulo 4.

Los tres desastres de coordinar mal

Cuando order-triage era un flujo solitario, su único drama era el del Módulo 1: dispararse dos veces y duplicar sus propios efectos. Ahora que coordina a otros tres, aparecen tres desastres nuevos, y son los tres que este módulo existe para evitar. Vale la pena nombrarlos desde ya, con precisión, porque cada lección ataca uno o varios.

Desastre 1 — La cascada

Una cascada es cuando el fallo de un workflow arrastra a los que dependen de él, y el daño se propaga hacia afuera como las fichas de un dominó.

Imagina que check-credit —el que consulta el crédito del cliente— se pone lento porque el sistema del banco está saturado. order-triage lo llama y se queda esperando. Como order-triage está bloqueado esperando a check-credit, no puede atender el siguiente pedido, que se acumula. Y el proveedor que manda los pedidos, al no recibir confirmación de order-triage, empieza a reintentar, lo que mete todavía más pedidos a la cola. Un solo servicio lento —el del banco— terminó frenando el sistema completo y multiplicando la carga. Eso es una cascada: el problema no se quedó donde nació, se derramó.

Desastre 2 — La pérdida de orden

La pérdida de orden es cuando dos eventos que deberían procesarse en cierta secuencia se procesan al revés, y el resultado queda inconsistente.

Un cliente de Cumbre hace un pedido y, treinta segundos después, lo modifica. Llegan dos eventos para el mismo order_id: primero "pedido de 12 kg", después "corrección: son 8 kg". Si tu sistema procesa esos dos eventos en paralelo, o si el segundo se adelanta al primero, inventory-sync puede terminar descontando 12 kg cuando debía descontar 8, o aplicar la corrección antes que el pedido original y dejar el stock en un estado que no corresponde a ninguna de las dos versiones. El orden importaba, y se perdió. La lección 5 se dedica entera a esto.

Desastre 3 — El efecto duplicado

El efecto duplicado es el viejo conocido del Módulo 1, pero ahora con una fuente nueva: no solo se duplica porque un flujo corre dos veces, sino porque dos flujos distintos hacen lo mismo sin saber el uno del otro.

Supón que order-triage decide que un pedido cancelado necesita un reembolso, y llama a issue-refund. Justo en ese momento, un empleado, viendo la misma cancelación en el CRM, dispara manualmente otro flujo que también emite el reembolso. Dos caminos independientes, un solo reembolso debido, dos reembolsos emitidos. O más sutil: order-triage llama a issue-refund, issue-refund tarda en responder, order-triage reintenta la llamada, y ahora hay dos ejecuciones de issue-refund en vuelo para el mismo pedido. En un sistema de un solo flujo aprendiste a protegerte de tu propio doble disparo. En un sistema de varios, el doble disparo puede venir de un flujo vecino.

Y hay algo peor que conviene anticipar: los tres desastres se alimentan entre sí. Una cascada, al frenar el sistema, hace que el proveedor reintente, lo que multiplica los disparos —y esos disparos duplicados, bajo carga, llegan desordenados—. Es decir, empiezas con una pieza lenta (cascada), y terminas con eventos duplicados y desordenados (los otros dos desastres) como consecuencia. Rara vez enfrentas uno solo; en producción, un incidente real suele ser los tres enredados. Por eso no alcanza con parchar cada uno por su lado: hace falta un diseño que los prevenga de raíz.

Estos tres desastres tienen algo en común, y es la buena noticia: todos se resuelven con las mismas dos ideas que ya traes —efectos idempotentes y una memoria compartida durable (el ledger)— más un patrón nuevo que las junta, el outbox de la lección 6. No vas a aprender tres soluciones distintas para tres problemas. Vas a aprender a aplicar lo que ya sabes al nivel del sistema. Esa economía —pocas ideas, bien combinadas, contra muchos síntomas— es la marca de un buen diseño, y es lo que hace que este módulo, aunque cubra mucho terreno, se sostenga sobre un puñado de principios que ya conoces.

La pieza que lo cambia todo: el ledger como memoria compartida

Antes de listar la promesa del módulo, quiero adelantarte la idea que hace posible todo lo demás, porque le va a dar sentido a cada lección. Es la reutilización de algo que ya construiste.

En el Módulo 4 armaste un run ledger: una tabla en Postgres donde el sistema anota qué ejecuciones ya ocurrieron, para poder detectar un disparo duplicado. En ese módulo, el ledger era la memoria de un workflow: order-triage anotaba "ya procesé el pedido ORD-2041" para no procesarlo de nuevo si el webhook se disparaba dos veces.

La jugada de este módulo es sencilla de decir y potente en sus consecuencias: ese mismo ledger, compartido por los cuatro workflows, se convierte en la memoria del sistema entero. No de un flujo. De todos.

Piénsalo como el pizarrón de una cocina de restaurante. En una cocina bien llevada hay un pizarrón donde se anota qué platos ya salieron. Cualquier cocinero, antes de empezar un plato, mira el pizarrón: si el plato de la mesa 4 ya está tachado, no lo vuelve a preparar, aunque el mesero se lo pida otra vez por error. El pizarrón no le pertenece a ningún cocinero; es de la cocina, y su valor es justamente que todos lo leen y todos lo escriben. Sin él, dos cocineros pueden preparar el mismo plato sin enterarse. Con él, el trabajo ya hecho es visible para todos.

El ledger es ese pizarrón. Cuando issue-refund va a emitir un reembolso para ORD-2041, primero mira el ledger: "¿ya se emitió el reembolso de este pedido?". Si sí, no lo emite de nuevo. Cuando lo emite, lo anota. Y como el ledger es compartido, si otro flujo —o una segunda ejecución del mismo— pregunta lo mismo un segundo después, ve que ya está hecho. El efecto duplicado del desastre 3 se previene porque el trabajo hecho por un flujo es visible para todos los demás.

Esta idea —una memoria durable y compartida contra la cual cada efecto se verifica antes de ejecutarse— es el hilo que cose el módulo completo. El grafo de dependencias (lección 3) te dice quién consulta el pizarrón; el patrón outbox (lección 6) te da la forma disciplinada de escribir en él sin perder ni duplicar; la delegación entre agentes (lección 7) usa el pizarrón para que dos agentes no hagan el mismo trabajo. Todo apunta al mismo lugar. Si en algún momento del módulo te sientes perdido, vuelve a esta imagen: el pizarrón de la cocina, que todos leen antes de actuar.

Qué te promete este módulo

Al terminar las ocho lecciones vas a poder tomar un sistema de varios workflows —los cuatro de Cumbre, o los que tengas en tu trabajo— y:

Dibujar su grafo de dependencias. Un diagrama de quién llama a quién, con qué tipo de conexión, y qué se propaga si una pieza falla. Suena simple y es la herramienta que más veces te va a salvar: la mitad de los bugs de coordinación se ven a simple vista en el grafo, antes de escribir una línea.

Elegir cómo coordinar. Vas a saber cuándo conviene un director central que llama a cada pieza en orden, y cuándo conviene que las piezas reaccionen a eventos sin director. No es una preferencia estética: cada opción tiene un costo distinto en visibilidad, acoplamiento y resistencia a fallos.

Coordinar sin duplicar. Con el patrón outbox y el ledger, vas a poder hacer que una caída a la mitad de una cadena de workflows no deje el sistema ni con un efecto perdido ni con un efecto duplicado. Es la capacidad central del módulo.

Delegar entre agentes con seguridad. Cuando un AI Agent le pasa trabajo a otro —como viste en la guía de chatbots—, vas a poder garantizar que ningún agente repita un efecto que otro ya hizo, usando el ledger como memoria compartida y límites de iteración como freno. Es la misma coordinación de siempre, aplicada a actores que razonan en vez de a nodos fijos, y por eso más delicada.

El mapa de este módulo

Las ocho lecciones van del dibujo a la práctica. Fíjate en el orden, porque cada bloque se apoya en el anterior:

Lección	Qué resuelve
2	Las dos formas de coordinar: orquestación (un director llama a todos) vs coreografía (cada pieza reacciona a eventos). Ventajas, riesgos y cuándo conviene cada una.
3	Cómo dibujar el grafo de dependencias de un sistema real: quién dispara a quién, dónde hay ciclos, y hasta dónde se propaga un fallo.
4	Fan-out y fan-in: repartir trabajo en varias ramas o sub-ejecuciones y volver a juntarlas sin perder ni duplicar items. El riesgo del reintento parcial.
5	Orden y contrapresión: qué pasa cuando los eventos llegan más rápido de lo que se procesan, y cómo el queue mode de n8n da capacidad y control de ritmo.
6	El patrón outbox: separar "decidir el efecto" de "ejecutar el efecto", para que un fallo entre pasos no duplique ni pierda nada. La técnica central del módulo.
7	Delegación entre agentes: cómo dos agentes que se pasan tareas no disparan el mismo efecto dos veces ni entran en bucle.
8	El proyecto: coordinar check-credit, issue-refund e inventory-sync con un director, un outbox y un ejecutor idempotente, y probar que una caída a la mitad no duplica ni pierde efectos.

La progresión tiene una lógica: primero las dos formas de coordinar (2), después la herramienta para verlas —el grafo— (3), después los dos problemas mecánicos de repartir y de ritmo (4 y 5), después el patrón que resuelve la coordinación (6), después su aplicación a agentes (7), y al final la práctica que lo junta todo (8). Cuando termines, la coordinación de varios workflows va a dejar de darte esa sensación de "no sé bien qué está pasando ahí adentro" y va a ser algo que puedes dibujar, razonar y probar.

Una aclaración de alcance

Este módulo diseña la correctitud de la coordinación: que el sistema no haga daño aunque una pieza falle, se repita o se atrase. No cubre operarlo a escala en producción —montar un clúster de workers de queue mode, dimensionar Redis, monitorear la latencia entre workflows en un dashboard—. Eso es trabajo de la guía de producción y mantenimiento, y la frontera se declara explícitamente al final del Módulo 6. Cuando en la lección 5 hablemos de queue mode, lo vamos a tratar como el mecanismo que da capacidad y control de ritmo, no como un ejercicio de configuración de infraestructura. Vas a entender qué es y por qué importa para el orden; cómo afinarlo para mil pedidos por minuto es otra guía.

El laboratorio y una nota sobre las fechas

A partir de la lección 4 vas a construir de verdad, y todo corre a costo cero sobre la misma instancia self-hosted Community con el Starter Kit del Módulo 4 —n8n más un Postgres local—. No necesitas servicios de pago ni una tarjeta: el ledger, el outbox y los efectos simulados viven en tu propio Postgres. Si llegaste hasta aquí siguiendo la guía, ya lo tienes montado; si te saltaste el Módulo 4, ese es el lugar donde se arma pieza por pieza.

Y una honestidad que conviene decir desde ya, en el espíritu de que cada dato con fecha envejece: los nombres exactos de algunos nodos y opciones de n8n cambian entre versiones. Esta guía se escribió con n8n 2.x a mediados de 2026. Cuando un nombre exacto importe —la opción que hace que un Execute Sub-workflow espere el resultado, el nodo que junta ramas, las variables del queue mode— te lo voy a señalar y te voy a pedir que verifiques la etiqueta en tu propio panel y en la documentación oficial. El concepto no cambia; el texto de un botón, a veces sí. Anotar la versión que usas es un hábito que paga: cuando algo de la guía no coincida con tu pantalla, la primera pregunta siempre es "¿qué versión tengo?".

Errores comunes

Creer que si cada workflow funciona, el sistema funciona (conceptual). Qué pasa: alguien prueba order-triage, prueba check-credit, prueba issue-refund e inventory-sync, cada uno por separado con un caso feliz, ve los cuatro en verde y concluye que el sistema está listo. En producción aparece un cobro duplicado que ninguno de los cuatro flujos, mirado por separado, explica. Por qué pasa: los desastres de coordinación no viven dentro de ningún flujo, viven en cómo se conectan —en qué pasa cuando order-triage reintenta a issue-refund, o cuando dos eventos del mismo pedido corren a la vez—. Probar las piezas por separado nunca prueba eso. Cómo detectarlo: pregúntate "¿qué probé exactamente?". Si la respuesta es "que cada workflow procesa una entrada correcta", no probaste la coordinación. Cómo corregirlo: las pruebas que importan en este módulo son las de la costura —dispara order-triage dos veces seguidas, mata issue-refund a la mitad, manda dos eventos del mismo order_id— y esas son exactamente las que arma el proyecto de la lección 8.

Meter todo en un solo workflow gigante para "no tener que coordinar" (conceptual). Qué pasa: para evitar la complejidad de varios flujos, alguien pone la consulta de crédito, el reembolso y el descuento de inventario dentro de order-triage, todo en una sola cadena de nodos. Por qué pasa: parece que un solo flujo es más simple de entender y no tiene "conexiones" que puedan fallar. Cómo detectarlo: si un cambio en la lógica de reembolsos te obliga a abrir, entender y arriesgar el flujo que también recibe pedidos y descuenta inventario, tu flujo hace demasiado. Cómo corregirlo: separar por dominio es lo correcto —cada pieza se prueba, versiona y reutiliza aparte, como enseñó el Módulo 3—; lo que hay que aprender no es a evitar la coordinación, sino a hacerla segura, que es justo lo de este módulo. El monolito no elimina los desastres, solo los esconde adentro de un flujo donde son más difíciles de ver.

Suponer que "llamar a otro workflow" es instantáneo y siempre funciona (conceptual). Qué pasa: se diseña la coordinación como si order-triage llamara a issue-refund y el resultado volviera al instante, sin contemplar que la llamada puede tardar, fallar a la mitad, o volver después de que order-triage ya se rindió. Por qué pasa: en la demo, con todo local y rápido, las llamadas entre workflows son casi instantáneas y siempre exitosas, así que la posibilidad del fallo no se siente real. Cómo detectarlo: por cada flecha de tu grafo de dependencias, pregúntate "¿qué pasa si esta llamada tarda diez segundos?" y "¿qué pasa si nunca vuelve?". Si no tienes respuesta, ese es un punto frágil. Cómo corregirlo: tratar cada llamada entre workflows como lo que es —una operación que puede fallar, tardar o repetirse— es la mentalidad de todo el módulo, y el patrón outbox de la lección 6 es la herramienta que la vuelve concreta.

Ejercicios

Ejercicio 1 — Clasifica los cuatro workflows. Sin volver a mirar la tabla de esta lección, escribe cuáles de los cuatro workflows de Cumbre —order-triage, check-credit, issue-refund, inventory-sync— son lecturas y cuáles son efectos, y para cada efecto di qué daño concreto haría si se ejecutara dos veces para el mismo pedido.

Ver solución

check-credit es una lectura: consulta el crédito disponible del cliente y no cambia nada. Consultarlo dos veces da la misma respuesta y no hace daño.

issue-refund e inventory-sync son efectos. Si issue-refund corre dos veces para el mismo pedido, emite dos reembolsos: el cliente recibe de vuelta el doble de lo que le correspondía, o se le devuelve algo que ya se le había devuelto. Si inventory-sync corre dos veces, descuenta el doble de unidades: la bodega queda con un stock más bajo que el real, y eventualmente el sistema rechaza pedidos de producto que sí hay.

order-triage es el coordinador: su trabajo no es tanto un efecto propio como decidir qué efectos disparar. Su duplicación es peligrosa justamente porque, al correr dos veces, puede disparar dos veces los efectos de los otros.

Por qué funciona: acabas de identificar dónde está el peligro real del sistema. Todo lo que sigue en el módulo es proteger esos dos efectos —issue-refund e inventory-sync— de dispararse más veces de las debidas, sin importar por cuál de los tres desastres venga la amenaza.

Ejercicio 2 — Empareja el desastre con la escena. Para cada una de estas tres escenas, di cuál de los tres desastres es —cascada, pérdida de orden o efecto duplicado— y justifica en una frase:

(a) El sistema del banco se pone lento, check-credit se cuelga, order-triage deja de atender pedidos y el proveedor empieza a reintentar, saturando todo. (b) Un cliente pide 12 kg y corrige a 8 kg treinta segundos después; los dos eventos se procesan en paralelo e inventory-sync termina descontando 12. (c) order-triage llama a issue-refund, no recibe respuesta a tiempo, reintenta, y quedan dos ejecuciones de issue-refund emitiendo el mismo reembolso.

Ver solución

(a) Cascada. El fallo nació en un servicio (el banco) y se propagó hacia afuera: colgó a check-credit, luego a order-triage, y terminó saturando la entrada. El daño no se quedó donde empezó.

(b) Pérdida de orden. Los dos eventos del mismo pedido tenían una secuencia correcta —primero el pedido, después la corrección— y se procesaron al revés o en paralelo, dejando el stock en un estado que no corresponde a la versión final del pedido.

(c) Efecto duplicado. Un solo reembolso debido, dos ejecuciones emitiéndolo, por culpa de un reintento que no supo que la primera llamada seguía en vuelo. Es el mismo daño del Módulo 1, pero disparado por la coordinación entre dos flujos.

Por qué funciona: reconocer de qué desastre se trata es el primer paso para saber qué herramienta aplicar. La cascada se ataca con orden y contrapresión (lección 5) y con desacoplar (lección 2); la pérdida de orden, con la lección 5; el efecto duplicado, con idempotencia y el outbox (lecciones 6 y 7). Ponerle nombre al problema es media solución.

Ejercicio 3 — Dibuja el sistema que conozcas. Piensa en algún sistema real que uses o hayas usado —un e-commerce, un sistema de reservas, el flujo de alta de un empleado en tu trabajo— e intenta dibujar, con cajas y flechas, qué "workflows" o procesos lo componen y quién depende de quién. No tiene que ser exacto. Marca al menos un lugar donde creas que un fallo se propagaría a otros.

Ver solución

No hay una respuesta única, y ese es el punto: casi cualquier sistema real, cuando lo dibujas, resulta ser varias piezas dependientes y no una sola. Un ejemplo típico, el alta de un empleado: un proceso central de "onboarding" que dispara la creación de la cuenta de correo, el alta en el sistema de nómina, la asignación de un equipo y el envío de un correo de bienvenida. El punto de propagación clásico está en que el correo de bienvenida depende de que la cuenta de correo ya exista: si la creación de la cuenta falla o tarda, el correo de bienvenida rebota o se manda a una dirección que todavía no funciona.

Si lograste marcar un punto donde un fallo se propaga, ya hiciste, en pequeño, lo que la lección 3 formaliza: encontrar en el grafo el lugar donde una pieza caída arrastra a otras. Ese instinto —mirar un sistema y preguntarte "¿qué se cae si esto se cae?"— es exactamente la mentalidad de dueño del sistema que la guía entera cultiva.

Resumen y siguiente paso

En esta lección diste el salto de un workflow solitario a un sistema de varios flujos dependientes. Viste que order-triage ya no está solo: coordina a check-credit (una lectura), issue-refund (un efecto que mueve dinero) e inventory-sync (un efecto que cambia el stock). Y nombraste con precisión los tres desastres que aparecen al coordinar mal: la cascada (un fallo que se propaga), la pérdida de orden (eventos que se procesan al revés) y el efecto duplicado (dos flujos haciendo lo mismo sin enterarse). La buena noticia que cierra la lección es que los tres se resuelven con lo que ya traes —efectos idempotentes (Módulo 2) y una memoria compartida durable, el ledger (Módulo 4)— más el patrón outbox que aprenderás en la lección 6.

Antes de avanzar a la lección 2 deberías poder: nombrar los cuatro workflows de Cumbre y decir cuáles son lecturas y cuáles efectos; describir en una frase cada uno de los tres desastres de la coordinación; y explicar por qué probar cada workflow por separado no prueba que el sistema esté bien.

Lo que sigue es la primera decisión de diseño de todo sistema de varios flujos: ¿los coordina un director central que los llama en orden, o cada pieza reacciona por su cuenta a los eventos que le importan? La lección 2 pone esas dos formas —orquestación y coreografía— una junto a la otra, con sus ventajas y sus riesgos, y te da el criterio para elegir. Es la decisión que va a dar forma a todo lo demás.

Recursos

• Execute Sub-workflow node — n8n Docs — el nodo con el que un workflow llama a otro y espera su resultado. Es la arista principal del grafo de dependencias que vas a dibujar en la lección 3; conviene tenerlo a la vista desde ya.
• Execute Sub-workflow Trigger — n8n Docs — el disparador del lado del workflow llamado, donde se declara el contrato de entrada que viste en el Módulo 3.
• Sub-workflows — n8n Docs — la visión general de por qué y cómo se parte un sistema en varios workflows que se llaman entre sí; el punto de partida conceptual de este módulo.
• Release notes 2.x — n8n Docs — el historial de la línea 2 de n8n; útil para confirmar qué versión usas frente a lo que describe esta guía, porque los nombres de algunos nodos cambian entre versiones menores.