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

Paralelismo con Sincronización (Wait Mode)

Siguiente →

Descripción de la cápsula

Después del fan-out, las ramas paralelas pueden terminar en tiempos distintos. A veces eso está bien — cada rama hace su trabajo independientemente. Pero otras veces necesitas esperar a que todas terminen antes de continuar. Para reportes con múltiples fuentes, validaciones que requieren info de varios sistemas, o cualquier flujo "fork-join" — necesitas sincronizar.

Wait mode de Merge es la herramienta. En esta cápsula vas a profundizar cómo funciona, los patterns comunes (3 APIs paralelas → reporte único, validación multi-source), y las consideraciones de timeouts y ramas que fallan.

Lo que vas a aprender

  • ✅ Configurar Wait para sincronizar 2-N ramas
  • ✅ Manejar ramas con timing distinto
  • ✅ Aplicar al patrón fork-join clásico
  • ✅ Resolver casos donde una rama falla

El patrón fork-join

Fork: dividir en N ramas Join: convergir en una

              ┌─→ [rama A: 3s]
[Fork] ──────►┤
              ├─→ [rama B: 5s]
              │
              └─→ [rama C: 2s]
                       │
                       ▼ (espera todas)
                  [Merge: Wait]
                       │
                  [continuar con resultados]

Merge Wait espera 5 segundos (la rama más lenta), después continúa.

Caso 1: Reporte con 3 fuentes paralelas

Caso: reporte diario consulta Stripe + Shopify + HubSpot. Cada API responde en tiempos distintos.

[Schedule diario 8am]
   │
   ├─→ [HTTP: Stripe pagos]    (3s)
   ├─→ [HTTP: Shopify orders]   (5s)
   └─→ [HTTP: HubSpot deals]    (2s)
        │
        ▼
   [Merge: Wait]
        │
   [Set: combinar datos en reporte]
        │
   [Slack: reporte unificado]

Tiempo total: 5 segundos (la más lenta) en vez de 10 (suma de las 3 secuenciales).

Caso 2: Validación multi-source

Caso: antes de aprobar una compra grande, verificar 3 cosas en paralelo:

  • Crédito del cliente (API interna)
  • Stock disponible (Shopify)
  • Score de riesgo (servicio externo)
[Order recibido]
   │
   ├─→ [API: credit check]
   ├─→ [API: stock check]
   └─→ [API: risk score]
        │
        ▼
   [Merge: Wait]
        │
   [Set: agregar todos los results]
        │
   [IF: credit OK && stock OK && risk OK]
   ├─ TRUE → [API: aprobar order]
   └─ FALSE → [API: rechazar order + razones]

Las 3 verificaciones en paralelo (rápido), después decisión combinada.

Configuración de Wait

En el Merge node:

  • Mode: Wait

Eso es todo. n8n espera a que todos los inputs lleguen.

Comportamiento

  • Si una rama tarda 3s y otra 5s → Wait completa después de 5s
  • Output del Merge: los items de ambas ramas en orden (no fusionados — separados como items)

Acceso a datos del Merge

Después del Wait, puedes acceder a outputs de cada rama:

// Items del input 1 (rama A)
{{ $input.first().json }}

// Items del input 2 (rama B)
{{ $input.last().json }}

// O por orden
{{ $items('NodeNameA') }}

Cuándo NO usar Wait

Ramas independientes que terminan en destinos separados

[Trigger]
   ├─→ [API A] → [Slack #channel-a]
   ├─→ [API B] → [Sheet append]
   └─→ [API C] → [Email user]

Cada rama tiene su destino. No necesitas Wait — el workflow termina cuando todas terminen, sin sincronización explícita.

Cuando una rama puede tardar muchísimo

Si la rama A tarda 5s y la B puede tardar 5 minutos, Wait detiene todo 5 min. Considerar:

  • Hacer la rama B asíncrona (con Wait node propio que reanuda con webhook)
  • O no usar Wait — dejar que cada rama complete su trabajo independientemente

Trampas comunes

Trampa 1: Una rama falla — Wait cuelga

Qué pasa: 2 ramas paralelas. Una falla. Wait nunca recibe sus datos. Workflow se cuelga.

Cómo evitar:

  • Continue On Fail en las ramas
  • O capturar errores y producir item vacío para que Wait continúe

Trampa 2: Wait con 2 ramas que tienen distinto cantidad de items

Qué pasa: Rama A produce 10 items. Rama B produce 5. Wait combina cómo?

Depende del modo de input del Merge:

  • Algunos modos asumen mismo cantidad
  • Otros manejan diferentes cantidades pero pueden ser confusos

Cómo evitar: Para Wait sincronización, idealmente cada rama produce 1 item agregado (con Aggregate). Eso evita ambigüedades.

Trampa 3: Esperar cuando no necesitas

Qué pasa: Usas Wait "por seguridad" pero las ramas no necesitan converger. Workflow innecesariamente más lento (espera a la más lenta).

Cómo evitar: Wait solo cuando después del Merge hay procesamiento que necesita datos de todas las ramas.

Trampa 4: 5+ inputs al Wait

Qué pasa: Tienes 6 ramas paralelas que convergen en Wait. n8n soporta múltiples inputs en Merge, pero la lógica se complica.

Cómo evitar:

  • Si tienes 5+ fuentes, considera estructura jerárquica: agrupar 3 en un Wait, otras 3 en otro Wait, después un Wait final que une los 2
  • O usar un sub-workflow que orqueste las llamadas

Ejercicio: workflow fork-join

Objetivo: practicar el patrón completo.

Tu tarea

Construye:

  1. Manual Trigger
  2. 3 ramas paralelas con HTTP a APIs públicas:
  3. Merge Wait
  4. Set que combina los 3 results
  5. Slack o log con resultado combinado

Verifica:

  • ¿Tiempo total ≈ la rama más lenta?
  • ¿Output del Set tiene datos de las 3?

Resumen y siguiente paso

  • Wait mode sincroniza ramas paralelas
  • Tiempo total = la rama más lenta
  • Patrón fork-join: múltiples APIs paralelas → join → procesamiento combinado
  • NO usar Wait cuando ramas son independientes con destinos propios
  • 4 trampas: rama fallida cuelga, cantidades distintas, esperar sin necesidad, 5+ inputs

Lo que sigue: Fan-out condicional — cuando las ramas paralelas dependen de la categoría del input.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorPatrón: Combinar Fuentes con CombineSiguiente →Fan-Out Condicional