Módulo 4: Merge Avanzado y Fan-Out / Fan-In
Introducción al Módulo: Merge Avanzado y Fan-Out/Fan-In
Descripción de la cápsula
Hasta acá los workflows tuvieron flujo principal lineal: trigger, procesamiento secuencial, salida. M04 te enseña flujos paralelos: dividir el workflow en N caminos simultáneos (fan-out), procesar cada uno independientemente, y combinar resultados (fan-in). Es el patrón que necesitas cuando consultas múltiples APIs en paralelo, procesas categorías distintas con misma estructura, o construyes reportes que requieren info de fuentes diversas.
En G1-M07-04 viste Merge básico (Append, Combine, Multiplex, Wait). Este módulo profundiza: cuándo cada modo, cómo diseñar flows paralelos mantenibles, los patterns para sincronizar (esperar a que todas las ramas terminen), y los anti-patterns del parallel processing.
Lo que vas a aprender
Al terminar este módulo serás capaz de:
- ✅ Diseñar flujos fan-out dividiendo procesamiento en N ramas paralelas
- ✅ Combinar resultados con fan-in usando Merge en sus diferentes modos
- ✅ Sincronizar ramas que terminan en tiempos distintos
- ✅ Combinar fuentes de datos (Sheets + API + DB) con JOINs limpios
- ✅ Aplicar los modos avanzados del Merge node
Estructura del módulo
8 cápsulas:
- Introducción al módulo
- Fan-out: dividir en ramas paralelas — cómo y cuándo
- Merge: modos profundizados — Append, Combine, Multiplex, Wait detalle
- Patrón: combinar fuentes con Combine — JOIN tipo SQL
- Patrón: paralelismo con sincronización — Wait mode para esperar todas
- Patrón: fan-out condicional — diferentes ramas según categoría
- Anti-patterns y trampas — qué evitar
- Mini-proyecto: 3 fuentes paralelas a reporte único
El modelo mental: fan-out / fan-in
Fan-out: el workflow se abre como abanico. Un input dispara N procesamientos paralelos.
Fan-in: los N procesamientos convergen en uno. Resultados se combinan.
┌─→ rama A ─┐ [Trigger] ────────►┤ ├─→ [Merge: fan-in] → resultado único └─→ rama B ─┘
Es la arquitectura de map-reduce clásica de procesamiento paralelo, adaptada a n8n.
¿Por qué importa?
Razón 1: Performance
Si tienes 3 APIs a consultar y cada una tarda 5 segundos:
- Secuencial: 15 segundos total
- Paralelo: 5 segundos total (la más lenta)
3× speedup gratis.
Razón 2: Reportes con múltiples fuentes
Reporte diario que consulta Stripe + Shopify + HubSpot. Cada uno independiente. Paralelizar es natural y eficiente.
Razón 3: Independencia entre tareas
Si la API A está caída pero la B funciona, en paralelo B sigue. En secuencial, A bloquearía B.
Cuándo NO usar paralelismo
- Cuando una tarea depende del resultado de otra (debe ser secuencial)
- Cuando suman al mismo destino (paralelismo crea race conditions)
- Cuando es 1 API call simple (overhead no vale la pena)
Pre-requisitos
- G1-M07 (incluye Merge básico)
- G2-M02 (branching avanzado)
- G2-M03 (iteración)
Tiempo estimado
1.5-2 horas. División sugerida:
- Sesión 1 (45 min): 01-03 (intro + fan-out + merge profundo)
- Sesión 2 (45 min): 04-06 (combinar fuentes, sync, condicional)
- Sesión 3 (30 min): 07-08 (anti-patterns + proyecto)
Recursos adicionales
Creado: Mayo 11, 2026 Versión: 1.0