Módulo 4: Merge Avanzado y Fan-Out / Fan-In

Fan-Out: Dividir en Ramas Paralelas

Siguiente →

Descripción de la cápsula

Fan-out es el patrón de abrir el workflow en múltiples ramas que ejecutan en paralelo. Visualmente: un input, varios outputs simultáneos. Cada rama hace su trabajo independientemente, sin esperar a las otras. Es la base para todo lo que sigue en el módulo: sin fan-out no hay paralelismo, sin paralelismo no hay performance gains de procesar múltiples fuentes/operaciones.

En esta cápsula vas a aprender cómo se implementa fan-out en n8n (es más simple de lo que parece), cuándo aplicarlo, los 3 casos típicos (multi-API, procesamiento de categorías independientes, notificaciones múltiples), y las consideraciones de paralelismo real vs aparente (n8n cloud vs self-hosted).

Lo que vas a aprender

  • ✅ Implementar fan-out conectando 1 nodo a N nodos siguientes
  • ✅ Aplicar a 3 casos típicos
  • ✅ Entender el paralelismo real de n8n
  • ✅ Decidir cuándo fan-out vale la pena

Cómo se implementa

Simplísimo: desde la salida de un nodo, conectas a múltiples nodos siguientes.

                ┌─→ [Nodo A]
   [Input] ────►┤
                ├─→ [Nodo B]
                │
                └─→ [Nodo C]

En el canvas: arrastra del output del nodo 1 a 3 nodos diferentes. n8n los ejecuta en paralelo.

Paralelismo real en n8n

Importante: en muchas configuraciones de n8n, las ramas se ejecutan secuencialmente bajo el capó aunque visualmente parezcan paralelas. n8n procesa una rama, luego otra, luego otra.

Cuándo es realmente paralelo

  • n8n Cloud Pro/Enterprise: mejor concurrencia
  • Self-hosted con configuración avanzada: queues + workers separados
  • Cuando llamas APIs externas: las APIs procesan en paralelo aunque n8n inicia secuencialmente, así que el tiempo total se acerca al paralelo

Cuándo es secuencial

  • n8n Cloud Starter: ramas se procesan en orden
  • Self-hosted single-worker: mismo
  • Operaciones intensivas locales: Code node pesado, etc.

Implicación

  • Para APIs externas: fan-out da speedup real (las APIs son concurrentes)
  • Para lógica local: fan-out estructura el código pero no acelera mucho

Caso 1: Multi-API parallel

Caso: reporte que consulta 3 APIs.

[Schedule diario]
   │
   ├─→ [HTTP: Stripe pagos del día]
   ├─→ [HTTP: Shopify pedidos del día]
   └─→ [HTTP: HubSpot leads del día]
        │
        ▼
[Merge: Wait — espera a las 3]
        │
[Reporte combinado]
        │
[Slack]

Beneficio: las 3 APIs responden en paralelo. Si cada una tarda 3s, total ~3s (no 9s).

Caso 2: Procesamiento independiente

Caso: un webhook trae datos. Quieres hacer 3 cosas con esos datos, ninguna depende de otra.

[Webhook]
   │
   ├─→ [Slack: notificar equipo]
   ├─→ [Sheet: guardar log]
   └─→ [CRM: crear contacto]

Las 3 ramas no comparten estado. Paralelizar es seguro.

Caso 3: Notificaciones múltiples canales

Caso: alerta importante debe ir a 3 canales.

[Trigger]
   │
   ├─→ [Slack: canal-alerts]
   ├─→ [Email: admin@empresa.com]
   └─→ [SMS via Twilio: oncall]

Cuándo fan-out NO vale la pena

1 rama es trivial

[Trigger]
   │
   ├─→ [Set: agregar campo X] ← rama trivial
   └─→ [API call lenta]

Mejor secuencial: Set → API.

Las ramas dependen entre sí

[Trigger]
   │
   ├─→ [Hacer X] ← depende del resultado de Y
   └─→ [Hacer Y]

Si X depende de Y, no son paralelos — son secuenciales mal estructurados.

Tu plan no soporta concurrencia

Si n8n cloud Starter, paralelismo visual no acelera. Estructurar como fan-out solo aporta legibilidad, no performance.

Diseño: fan-out con sincronización

Si las ramas paralelas deben converger (fan-in) al final, usar Merge en modo Wait:

[Trigger]
   ├─→ [rama A]──┐
   ├─→ [rama B]──┼─→ [Merge: Wait] → [acción final con resultados de las 3]
   └─→ [rama C]──┘

Wait mode espera a que las 3 lleguen antes de continuar. Cubierto en cápsula 05.

Trampas comunes

Trampa 1: Asumir paralelismo y rate limits compartidos

Qué pasa: 3 ramas paralelas llaman al mismo API. Cada rama 100 requests. Total: 300 requests "simultáneos" → rate limit.

Cómo evitar: Si las ramas comparten API, el rate limit es global. Considera cómo dividir respetando el límite total.

Trampa 2: Rama que escribe al mismo lugar — race condition

Qué pasa: 3 ramas paralelas que appenden al mismo Sheet. n8n hace requests rápidos → algunos se pierden o se duplican por race.

Cómo evitar: Centralizar la escritura: convergir con Merge antes de escribir.

Trampa 3: Fan-out sin fan-in cuando lo necesitas

Qué pasa: Fan-out de 3 ramas que terminan en destinos distintos. Workflow continúa pero "termina antes" — los nodos del flow principal no esperan a las 3 ramas.

Cómo evitar: Si necesitas que algo pase después de todas, usar Merge Wait.

Resumen y siguiente paso

  • Fan-out: conectar 1 nodo a N nodos siguientes (paralelo)
  • Implementación: drag from output a múltiples nodos
  • Paralelismo real depende de n8n versión y configuración
  • 3 casos: multi-API, procesamiento independiente, notificaciones múltiples
  • No usar cuando ramas son triviales, dependen, o plan no soporta
  • 3 trampas: rate limits compartidos, race conditions, sin fan-in necesario

Lo que sigue: Merge profundizado — los 4 modos con casos y ejemplos detallados.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorIntroducción al Módulo: Merge Avanzado y Fan-Out/Fan-InSiguiente →Merge: Los 4 Modos Profundizados