2. Orquestación vs coreografía

Descripción

Al terminar esta lección vas a poder distinguir las dos formas fundamentales de coordinar varios workflows —orquestación, donde un flujo director llama a los demás y espera sus resultados, y coreografía, donde cada flujo reacciona por su cuenta a los eventos que le importan, sin director— y vas a poder elegir cuál conviene para una situación concreta, sabiendo qué ganas y qué pierdes con cada una. También vas a saber cómo se arma cada una en n8n: la orquestación con el nodo Execute Sub-workflow, y la coreografía con eventos entre webhooks o una tabla que se consulta.

Esto importa porque es la primera decisión de diseño de todo sistema de varios flujos, y es una de esas decisiones que, si la tomas sin querer, te persigue durante meses. Casi todo el mundo empieza orquestando sin darse cuenta —conecta un Execute Sub-workflow y ya está— y eso está bien para muchos casos. Pero hay situaciones donde la orquestación crea justo la cascada que vimos en la lección 1, y donde la coreografía la evita. Saber nombrar las dos, y saber por qué elegiste la que elegiste, es lo que separa un sistema que crece con orden de uno que se enreda.

Conexión con el módulo: la lección 1 te dio el sistema de Cumbre y los tres desastres. Esta lección es la primera decisión sobre ese sistema: cómo se hablan los cuatro workflows. Las dos formas que veas aquí son las dos maneras de dibujar las flechas del grafo que armarás en la lección 3 —una flecha de orquestación significa "este llama a este y espera"; una de coreografía significa "este emite un evento y aquel reacciona"—. El patrón outbox de la lección 6 va a resultar ser, entre otras cosas, la forma de tener lo mejor de la coreografía (desacoplar) sin perder la seguridad. Así que esta lección planta el vocabulario que el resto del módulo desarrolla.

Dos formas de que varias piezas trabajen juntas

Piensa en dos maneras de que un grupo de músicos toque una canción coordinada.

La primera es una orquesta con director. Hay una persona al frente con una batuta. Los violines no entran cuando les parece: entran cuando el director les hace la señal. El director tiene la partitura completa en la cabeza, sabe qué sigue después de qué, y va marcando el momento de cada sección. Si quieres saber qué está pasando en la pieza, miras al director: él es el único punto donde vive el plan entero. La ventaja es el control total y la visibilidad —hay un solo lugar donde entender la coreografía—. La desventaja es que si el director se equivoca o se desmaya, la orquesta entera se detiene, porque nadie más tiene el plan.

La segunda es una banda de jazz improvisando. No hay director. El bajista empieza, el baterista lo escucha y entra con un ritmo que le calza, el saxofón oye a los dos y se suma. Nadie tiene la pieza completa escrita; cada músico reacciona a lo que oye de los demás y sabe cuál es su papel. La ventaja es que es resistente: si el saxofón se calla un momento, la banda sigue, porque nadie dependía de una señal central. La desventaja es que nadie tiene la foto completa —para entender qué va a pasar tienes que conocer las reglas de reacción de cada músico, no hay una partitura única que mirar—.

Esas dos formas son, exactamente, orquestación y coreografía. En la orquestación, un flujo director tiene el plan y le dice a cada pieza cuándo actuar. En la coreografía, no hay director: cada pieza reacciona a los eventos que percibe, siguiendo su propia regla. Las dos coordinan; lo hacen de formas opuestas, con costos opuestos. Veámoslas una por una.

Orquestación: un director que llama a cada pieza

En la orquestación, un workflow central —el director— tiene la secuencia completa y llama a cada sub-workflow en el orden que corresponde, esperando el resultado de cada uno antes de seguir.

Su anatomía en n8n es el nodo Execute Sub-workflow. Ya lo conoces del Módulo 3: es el nodo con el que un flujo llama a otro. Su comportamiento por defecto es el que hace posible la orquestación: espera a que el sub-workflow termine y recibe su resultado antes de pasar al siguiente nodo. En el panel del nodo esto es la opción Wait for Sub-Workflow Completion, que viene activada. Mientras order-triage espera a check-credit, no avanza; cuando check-credit devuelve su respuesta —"el cliente tiene crédito por $8,000"— order-triage la lee y decide qué hacer con ella.

Para Cumbre, un order-triage orquestador se vería así:

# Workflow: order-triage (el director)

Webhook (llega el pedido)
  → AI Agent (clasifica el pedido)
  → Execute Sub-workflow: check-credit          ← espera el resultado
  → IF (¿tiene crédito?)
      ├── sí → Execute Sub-workflow: inventory-sync   ← espera
      │        → HTTP Request: registrar en el CRM
      └── no → Execute Sub-workflow: issue-refund     ← espera
               → Send Email: aviso de crédito insuficiente

Lee ese flujo despacio, porque tiene la firma de la orquestación: el plan completo vive en order-triage. Si quieres saber en qué orden ocurren las cosas, qué llama a qué, y qué se decide dónde, lo lees todo en un solo workflow. check-credit, inventory-sync e issue-refund no saben nada del plan: cada uno recibe un encargo, lo resuelve, y devuelve su resultado. Son ejecutantes; el director es order-triage.

Las ventajas de la orquestación son tres, y son fuertes:

1. Visibilidad. El plan está en un solo lugar. Un colega nuevo abre order-triage y entiende el sistema entero. No tiene que ir juntando pistas de cuatro workflows.
2. Control del orden. Como el director espera cada resultado antes de seguir, la secuencia es exactamente la que escribiste. check-credit corre antes que inventory-sync, siempre, porque así está el flujo.
3. Decisiones sobre resultados. El director recibe el resultado de cada pieza y puede decidir el siguiente paso en función de él. "Si el crédito es insuficiente, no descuentes inventario, emite el aviso." Esa lógica condicional vive natural en el director.

Sus desventajas son el reverso de sus ventajas:

1. Acoplamiento. El director tiene que conocer a cada pieza: cómo se llama, qué contrato tiene, en qué orden va. Un cambio en check-credit puede obligar a tocar order-triage. Las piezas están amarradas al director.
2. El director es un punto único. Si order-triage se cae, nada corre, porque nadie más tiene el plan. Es el director que se desmaya y detiene la orquesta.
3. El riesgo de cascada. Como el director espera a cada pieza, un sub-workflow lento lo bloquea, y ese bloqueo se propaga hacia atrás —justo la cascada de la lección 1—. Si check-credit tarda diez segundos, order-triage tarda diez segundos de más, y los pedidos se acumulan en la entrada.

Coreografía: piezas que reaccionan a eventos, sin director

En la coreografía, no hay director. Cada workflow reacciona por su cuenta a un evento —algo que pasó— y hace su parte sin esperar a nadie ni ser esperado. El plan no vive en ningún lugar central: vive repartido en las reglas de reacción de cada pieza.

La anatomía en n8n es distinta, y aquí conviene una aclaración honesta: n8n no tiene un bus de eventos nativo tipo publicar/suscribir como el que tienen los sistemas grandes. Así que la coreografía en n8n se arma con las piezas que sí tiene, y hay dos formas comunes:

Forma A — eventos por webhook. Cuando order-triage termina de clasificar un pedido, en vez de llamar a los otros workflows, emite un evento: hace un HTTP Request a la URL de webhook de cada workflow interesado, o a un solo punto, diciendo "pasó esto: order.created, con estos datos". inventory-sync tiene su propio nodo Webhook escuchando ese evento y arranca solo. check-credit también. order-triage no espera a ninguno: emitió el evento y siguió con lo suyo.

Forma B — una tabla de eventos que se consulta. order-triage escribe una fila en una tabla —"evento: order.created, order_id: ORD-2041"— y cada workflow interesado tiene un Schedule Trigger que revisa esa tabla cada cierto tiempo, toma los eventos nuevos que le tocan, y los procesa. Nadie llama a nadie directamente; el punto de encuentro es la tabla. Esta forma, como vas a ver, es prima hermana del patrón outbox de la lección 6.

Para Cumbre, una versión coreografiada se vería así:

# Workflow: order-triage (ya no es director, es emisor)
Webhook (llega el pedido)
  → AI Agent (clasifica)
  → HTTP Request: emitir evento "order.created"   ← no espera a nadie
  → responde al proveedor y termina

# Workflow: inventory-sync (reacciona por su cuenta)
Webhook: escucha "order.created"
  → descuenta el inventario

# Workflow: check-credit (reacciona por su cuenta)
Webhook: escucha "order.created"
  → consulta el crédito
  → si es insuficiente, emite otro evento: "credit.rejected"

# Workflow: issue-refund (reacciona a otro evento)
Webhook: escucha "credit.rejected"
  → emite el reembolso

Fíjate en lo que cambió. order-triage ya no sabe que existe inventory-sync, ni check-credit, ni issue-refund. Solo sabe emitir el evento "order.created". Y issue-refund no sabe que existe order-triage: solo sabe que cuando pasa "credit.rejected", él emite el reembolso. Las piezas se comunican a través de los eventos, no a través de llamadas directas. Cada una es un músico de jazz reaccionando a lo que oye.

Las ventajas de la coreografía:

1. Desacoplamiento. order-triage no conoce a las piezas que reaccionan. Puedes agregar un quinto workflow que también escuche "order.created" —digamos, uno que mande el pedido a analítica— sin tocar order-triage para nada. Las piezas no están amarradas entre sí.
2. Resistencia. Como nadie espera a nadie, un workflow lento no bloquea a los demás. Si inventory-sync tarda, check-credit ya corrió igual, porque los dos reaccionaron al mismo evento de forma independiente. No hay director que se cuelgue y detenga todo.
3. Escalado independiente. Cada pieza corre a su ritmo. La que recibe mucha carga se puede reforzar sin tocar las demás.

Las desventajas, otra vez el reverso:

1. Nadie tiene la foto completa. Para entender qué pasa cuando llega un pedido, tienes que conocer las reglas de reacción de cuatro workflows y cómo encadenan sus eventos. No hay un solo lugar que leer. Depurar "¿por qué no se emitió el reembolso?" implica seguir el rastro de evento en evento.
2. El orden es más difícil de garantizar. Como las piezas reaccionan en paralelo y sin esperarse, asegurar que una cosa pase antes que otra requiere trabajo extra —justo el tema de la lección 5—.
3. Decidir sobre resultados es incómodo. En la orquestación, el director recibe el resultado de check-credit y decide. En la coreografía, check-credit tiene que emitir otro evento con su resultado para que alguien reaccione. La lógica condicional se reparte en cadenas de eventos, que son más difíciles de seguir que un nodo IF en un solo flujo.

Las dos, lado a lado

Vale la pena poner las diferencias en una tabla, porque son decisiones concretas y no de estilo:

Ninguna de las dos es "la buena". Son dos herramientas con perfiles opuestos, y elegir bien es cuestión de saber qué pesa más en tu caso.

Cuándo conviene cada una

La regla práctica, destilada de la tabla:

Orquesta cuando necesitas orden, resultados para decidir, y visibilidad. Si la lógica es "haz A, mira el resultado, si dio esto haz B, si no haz C", eso es un director. La cadena de Cumbre —consultar crédito, y según el crédito decidir si descuentas inventario o emites un aviso— es naturalmente orquestada, porque hay una decisión que depende de un resultado. Forzar eso a coreografía te llena de eventos "credit.approved" / "credit.rejected" que son más difíciles de seguir que un IF.

Coreografía cuando quieres desacoplar y las piezas no dependen del resultado de las otras. Si el evento "order.created" tiene que disparar tres cosas que no se necesitan entre sí —descontar inventario, mandar a analítica, notificar al equipo de ventas— eso es coreografía natural: las tres reaccionan al mismo evento, ninguna espera a las otras, y agregar una cuarta no toca nada. Forzar eso a orquestación amarra tres piezas independientes a un director que no aporta nada más que ser un cuello de botella.

Y algo que casi nadie dice al principio: la mayoría de los sistemas reales son una mezcla. No tienes que elegir uno para todo. Cumbre puede orquestar la cadena crédito-decisión-reembolso, porque ahí hay una secuencia con decisiones, y a la vez emitir un evento "order.created" que dispara en coreografía el descuento de inventario y la notificación de ventas, porque esos no dependen de nada. La pregunta no es "¿orquesto o coreografío mi sistema?", sino "¿esta parte concreta necesita orden y decisión (orquesta) o desacople (coreografía)?". Se decide arista por arista del grafo.

Ejemplo trabajado: la cadena de crédito de Cumbre, orquestada

Vamos a construir la parte orquestada del sistema —la cadena crédito-decisión— para que veas el mecanismo concreto. Es la parte donde la orquestación es claramente la opción correcta, porque hay una decisión que depende de un resultado.

Paso 1 — El sub-workflow check-credit con su contrato. check-credit es un workflow aparte que arranca con un Execute Sub-workflow Trigger. En ese trigger declaras el contrato de entrada con Define using fields below, como aprendiste en el Módulo 3: recibe un order_id, un customer_id y un amount. Su trabajo es consultar el crédito disponible y devolver una respuesta. Su último nodo —un Edit Fields— define lo que devuelve:

{
  "order_id": "ORD-2041",
  "credit_available": 8000.00,
  "credit_ok": true
}

Recuerda del Módulo 3: el último nodo del sub-workflow es el que devuelve los datos al nodo Execute Sub-workflow que lo llamó. check-credit es una lectura pura: consulta y devuelve, no cambia nada.

Paso 2 — El director llama y espera. En order-triage, después del AI Agent, pones un nodo Execute Sub-workflow configurado así:

# Nodo: Execute Sub-workflow — llamar a check-credit
Source: Database
Workflow: check-credit
Wait for Sub-Workflow Completion: activado   ← el director espera el resultado
Mode: Run once for each item
Workflow Inputs:
  order_id    = {{ $json.order_id }}
  customer_id = {{ $json.customer_id }}
  amount      = {{ $json.amount }}

Qué esperar. Cuando ejecutes order-triage con el pedido ORD-2041, vas a ver el nodo Execute Sub-workflow quedarse un momento "corriendo" mientras check-credit hace su trabajo, y después llenarse con la respuesta: el item de salida del Execute Sub-workflow trae los campos credit_available y credit_ok que devolvió el sub-workflow. Ese es el Wait for Sub-Workflow Completion en acción: el director esperó y recibió el resultado. Si abres la ejecución, vas a ver que check-credit aparece como una ejecución enlazada, no como parte de la de order-triage —son dos ejecuciones distintas, conectadas por la llamada—.

Paso 3 — El director decide sobre el resultado. Ahora que order-triage tiene el credit_ok, pones un nodo IF que decide el camino:

# Nodo: IF — ¿el crédito alcanza?
Condición: {{ $json.credit_ok }} es igual a true

  rama true  → Execute Sub-workflow: inventory-sync  (descuenta stock)
  rama false → Execute Sub-workflow: issue-refund    (emite el aviso/reembolso)

Esta es la razón por la que esta parte se orquesta y no se coreografía: la decisión depende del resultado de check-credit. El director lo lee y bifurca. En coreografía, tendrías que hacer que check-credit emitiera un evento distinto según el resultado, y que inventory-sync e issue-refund reaccionaran a eventos diferentes —más piezas, más difícil de seguir, para una lógica que aquí cabe en un IF—.

Un detalle honesto sobre esta cadena orquestada. Fíjate que inventory-sync e issue-refund son efectos, y los estamos llamando de forma inline, en el mismo flujo del director. Eso funciona, pero deja una grieta: si order-triage se cae justo después de descontar el inventario pero antes de registrar en el CRM, y luego se reintenta, va a descontar el inventario otra vez. La orquestación por sí sola no resuelve eso. Lo que lo resuelve es hacer esos efectos idempotentes (Módulo 2) y, mejor aún, sacarlos del flujo del director con el patrón outbox (lección 6). Por ahora quédate con la mecánica de la orquestación; la grieta la vamos a tapar en las próximas lecciones.

Un matiz que evita el error más común: síncrono no es lo mismo que orquestado

Hay una confusión que conviene deshacer, porque enreda a mucha gente. "Orquestado" y "síncrono" suenan a lo mismo, y no lo son.

Síncrono vs asíncrono es una pregunta sobre el tiempo: ¿el que llama espera la respuesta (síncrono) o sigue sin esperar (asíncrono)? El Execute Sub-workflow con Wait for Sub-Workflow Completion activado es síncrono; con esa opción desactivada, es asíncrono —dispara el sub-workflow y sigue sin esperar—.

Orquestación vs coreografía es una pregunta sobre quién tiene el plan: ¿un director central (orquestación) o reglas repartidas (coreografía)?

Son dos ejes distintos. Puedes tener orquestación asíncrona: un director que dispara varias piezas sin esperarlas y las recoge después —eso es justamente el fan-out de la lección 4—. Y la coreografía es casi siempre asíncrona, porque nadie espera a nadie. Cuando en el resto del módulo digamos "asíncrono", nos referimos al eje del tiempo; "coreografía" es el eje del plan. Tenerlos separados en la cabeza te ahorra discusiones confusas.

Errores comunes

Coreografiar una lógica que en realidad es una decisión secuencial (conceptual). Qué pasa: alguien, entusiasmado con el desacople, arma toda la cadena de Cumbre con eventos: "order.created" dispara check-credit, que emite "credit.checked", que dispara un workflow que decide, que emite "decision.made"... y termina con seis workflows y cinco tipos de evento para una lógica que era "consulta el crédito y bifurca". Por qué pasa: la coreografía suena más moderna y "desacoplada", y se aplica como si siempre fuera mejor. Cómo detectarlo: si para entender qué pasa con un pedido tienes que abrir cinco workflows y seguir una cadena de eventos que representa una sola decisión if/else, sobre-coreografiaste. Cómo corregirlo: donde hay una decisión que depende de un resultado, orquesta —un director con un IF es más claro y más fácil de depurar que una cadena de eventos—; reserva la coreografía para donde de verdad hay piezas independientes que no se necesitan entre sí.

Orquestar cosas independientes y crear un cuello de botella (conceptual). Qué pasa: order-triage llama en secuencia, esperando cada una, a inventory-sync, a un workflow de analítica y a uno de notificación, aunque las tres son independientes y ninguna necesita el resultado de las otras. El pedido tarda la suma de las tres, y si una se cae, las otras dos no corren. Por qué pasa: es lo más fácil de armar —conectas tres Execute Sub-workflow en fila— y en la demo, con todo rápido, no se nota el costo. Cómo detectarlo: si tienes varias llamadas en secuencia donde ninguna usa el resultado de la anterior, las estás serializando sin razón. Cómo corregirlo: si de verdad son independientes, o las disparas en coreografía (emites un evento y cada una reacciona) o las paralelizas con el fan-out de la lección 4; no las pongas en fila esperándose sin motivo.

Olvidar que Execute Sub-workflow espera por defecto (práctico). Qué pasa: alguien arma una cadena orquestada esperando que cada pieza corra en paralelo, pero como Wait for Sub-Workflow Completion viene activado, las piezas corren en fila, una tras otra, y el tiempo total es la suma —no el máximo—. O al revés: alguien desactiva esa opción para "que sea más rápido" y después su director intenta leer un resultado que nunca llegó, porque no esperó. Por qué pasa: el nombre de la opción y su valor por defecto no siempre están presentes en la cabeza al armar el flujo. Cómo detectarlo: si tu director "lee el resultado" de un sub-workflow, esa opción tiene que estar activada; si no lees ningún resultado y solo disparas, evalúa desactivarla. Cómo corregirlo: decide explícitamente, por cada Execute Sub-workflow, si necesitas el resultado (espera) o solo disparar (no esperes), y verifica el valor de la opción en el panel —su etiqueta exacta puede variar entre versiones, así que confírmala en tu instancia—.

Creer que la coreografía en n8n es "gratis" como en un sistema con bus de eventos (práctico). Qué pasa: alguien lee sobre arquitecturas dirigidas por eventos en sistemas grandes y asume que n8n tiene un bus de publicar/suscribir nativo donde emites un evento y "mágicamente" todos los interesados reaccionan. Se frustra al no encontrarlo. Por qué pasa: la teoría de eventos se explica casi siempre con herramientas que sí tienen ese bus, y n8n no lo tiene de forma nativa. Cómo detectarlo: si buscas un nodo "publicar evento" genérico y no aparece, es esto. Cómo corregirlo: en n8n, la coreografía se arma con las piezas reales que sí hay —un HTTP Request de un webhook a otro, o una tabla de eventos que cada workflow consulta con un Schedule Trigger—; la segunda forma, la tabla, es además la base del patrón outbox de la lección 6, así que no es un rodeo: es el camino.

Ejercicios

Ejercicio 1 — Clasifica cada arista. El sistema de Cumbre tiene estas cuatro relaciones. Para cada una, di si conviene orquestación o coreografía y por qué en una frase:

(a) order-triage consulta check-credit y, según el crédito, decide si descuenta inventario o emite un aviso. (b) Cuando entra un pedido, hay que descontarlo del inventario, mandarlo a un tablero de analítica y notificar al equipo de ventas; ninguna de las tres necesita el resultado de las otras. (c) issue-refund solo debe correr si check-credit determinó que no hay crédito. (d) Un quinto proceso, nuevo, quiere registrar cada pedido en un archivo de auditoría, sin afectar nada de lo demás.

Ejercicio 2 — Predice la cascada. En la versión orquestada de Cumbre, order-triage llama en secuencia y esperando a check-credit, inventory-sync e issue-refund. Un día, el sistema de bodega que usa inventory-sync se pone lento y cada llamada tarda 15 segundos en vez de 1. Describe qué le pasa al sistema completo, y luego di cómo la coreografía habría cambiado el desenlace.

Ejercicio 3 — Diseña la parte coreografiada. Cumbre quiere que, cuando entra un pedido, además de la cadena de crédito orquestada, se disparen en coreografía dos cosas independientes: registrar el pedido en un tablero de analítica y notificar al equipo de ventas si el monto supera $50,000. Diseña, con cajas y flechas, cómo se vería esa parte coreografiada: qué evento se emite, quién lo escucha y qué hace cada uno.

# order-triage, además de la cadena orquestada, emite un evento
order-triage
  → ...cadena de crédito orquestada...
  → HTTP Request: emitir evento "order.created"   ← no espera a nadie

# Dos workflows independientes reaccionan al mismo evento
analytics-logger
  Webhook: escucha "order.created"
    → registra el pedido en el tablero de analítica

sales-notifier
  Webhook: escucha "order.created"
    → IF: ¿amount > 50000?
        sí → Send Email / mensaje al equipo de ventas
        no → (no hace nada)

Resumen y siguiente paso

En esta lección separaste las dos formas de coordinar varios workflows. La orquestación pone el plan en un director central —en Cumbre, order-triage— que llama a cada pieza con Execute Sub-workflow, espera su resultado gracias a Wait for Sub-Workflow Completion, y decide el siguiente paso; te da visibilidad, control del orden y decisiones sobre resultados, a cambio de acoplamiento, un punto único de fallo y riesgo de cascada. La coreografía quita al director: cada pieza reacciona por su cuenta a eventos —por webhook o por una tabla que se consulta—; te da desacople, resistencia y escalado independiente, a cambio de perder la foto completa, dificultar el orden y volver incómodas las decisiones sobre resultados. Y viste que casi todo sistema real es una mezcla: se decide arista por arista, orquestando donde hay orden y decisión, coreografiando donde hay piezas independientes. Por último, separaste dos ejes que se confunden: síncrono/asíncrono es sobre el tiempo, orquestación/coreografía es sobre quién tiene el plan.

Antes de avanzar a la lección 3 deberías poder: explicar en una frase la diferencia entre orquestación y coreografía; decir qué opción del nodo Execute Sub-workflow hace que el director espere el resultado; y, dado un caso, decidir cuál de las dos conviene y por qué.

Ahora que sabes que las flechas entre workflows pueden ser de dos tipos —llamadas que esperan o eventos que reaccionan—, la lección 3 te enseña a dibujarlas todas juntas: el grafo de dependencias del sistema. Vas a aprender a poner sobre papel quién depende de quién, a marcar cada arista con su tipo, y —lo más valioso— a leer en ese dibujo hasta dónde se propaga un fallo antes de que ocurra. Es la herramienta que convierte "no sé bien qué pasa ahí adentro" en un diagrama que puedes razonar.

Recursos

• Execute Sub-workflow node — n8n Docs — el nodo del director: la opción Wait for Sub-Workflow Completion, los modos Run once for all items / Run once for each item, y el mapeo de Workflow Inputs. Verifica en tu versión la etiqueta exacta de la opción de espera.
• Execute Sub-workflow Trigger — n8n Docs — el disparador del sub-workflow, donde se declara el contrato con Define using fields below y donde se recuerda que el último nodo define la respuesta.
• Webhook node — n8n Docs — el nodo que hace posible la coreografía por eventos: cada workflow que reacciona tiene su propio webhook escuchando.
• Schedule Trigger — n8n Docs — el disparador para la coreografía por tabla: cada workflow revisa cada cierto tiempo la tabla de eventos y toma lo que le toca. Es la base del patrón outbox de la lección 6.
• Sub-workflows — n8n Docs — la visión general de cómo un sistema se compone de varios workflows que se llaman entre sí.