Módulo 4: Merge Avanzado y Fan-Out / Fan-In
Anti-Patterns y Trampas del Merge
Descripción de la cápsula
Has visto los patterns que funcionan. Esta cápsula es el opuesto: qué evitar. Errores comunes que parecen razonables al diseñar pero rompen workflows en producción. Reconocerlos te ahorra horas de debugging y previene incidentes.
Lo que vas a aprender
Identificar y evitar los 8 anti-patterns más comunes del paralelismo y merge.
Anti-pattern 1: Race condition al escribir al mismo destino
Síntoma: 3 ramas paralelas hacen Sheet append al mismo Sheet. Algunas filas se duplican, otras se pierden.
Por qué: Sheets/DBs no garantizan orden cuando recibe múltiples writes simultáneos. Algunos providers tienen "last write wins", otros "first write wins", otros "split brain".
Solución:
- Convergir antes de escribir. Un solo nodo de escritura al final, no múltiples.
- Si genuinamente necesitas paralelo, asegurar que escriben a lugares distintos (filas distintas, sheets distintos).
Anti-pattern 2: Merge sin saber qué modo es
Síntoma: Pones Merge entre 2 ramas sin pensar el modo. Default es Append. Esperabas Combine. Comportamiento extraño.
Por qué: Cada modo tiene comportamiento distinto. Default no siempre es correcto.
Solución:
- Siempre verificar el modo cuando configuras Merge
- Documentar con Sticky Note: "Merge mode: Combine Enrich by email"
Anti-pattern 3: Paralelismo aparente cuando es secuencial
Síntoma: Diseñaste fan-out para acelerar. Mediste — tarda igual que secuencial.
Por qué: En n8n Starter o single-worker, ramas se procesan secuencialmente bajo el capó. El paralelismo es visual pero no temporal.
Solución:
- Test con timing real antes de asumir speedup
- Si concurrencia importa: upgrade plan o usar webhook fan-out a sub-workflows
Anti-pattern 4: Wait con un input que nunca llega
Síntoma: Workflow se cuelga indefinidamente. Executions panel muestra "Running" sin avance.
Por qué: Wait espera a todos los inputs. Si una rama nunca produce output (falla silenciosa, infinite loop), Wait se cuelga.
Solución:
- Continue On Fail en cada rama
- Asegurar que cada rama siempre produce output (aún en error, un default item)
Anti-pattern 5: Combine con keys no comparables
Síntoma: Combine produce 0 matches aunque visualmente los datos coinciden.
Por qué: Tipos distintos ("1" vs 1), encoding distinto, whitespace, capitalization.
Solución:
- Set previo que normaliza ambos lados
- Inspeccionar Schema del input para verificar tipos
Anti-pattern 6: Fan-out a APIs con rate limit compartido
Síntoma: 5 ramas paralelas llaman la misma API. Recibes 429 (rate limit).
Por qué: Tu app tiene un rate limit total, no por rama. 5 ramas comparten ese límite.
Solución:
- No fan-out a la misma API sin coordinar
- Si necesitas, agregar Wait entre cada rama o usar SplitInBatches
Anti-pattern 7: Fan-out con efectos lateralizados
Síntoma: 4 ramas paralelas, cada una manda email. El destinatario recibe 4 emails (uno por rama).
Por qué: Cada rama es independiente y completa su trabajo.
Solución:
- Asegurar que cada rama hace algo distinto (no replicado)
- Si quieres "uno solo", convergir antes de la acción final
Anti-pattern 8: Workflow sobre-paralelo
Síntoma: Tu workflow tiene 6 ramas paralelas, cada una con 3 sub-ramas. 18 caminos. Imposible debuggear.
Por qué: Paralelismo es útil pero hay un límite de manageable complexity.
Solución:
- Limitar paralelismo a 2-4 ramas en un mismo punto
- Si necesitas más, extraer a sub-workflows
- Documentar exhaustivamente
Checklist antes de hacer fan-out
Antes de implementar paralelismo, pregúntate:
- ¿Las ramas son realmente independientes? (no comparten estado mutable)
- ¿La API compartida soporta el número total de requests?
- ¿Cada rama maneja sus errores (Continue On Fail)?
- ¿Si necesito sincronizar después, dónde y cómo?
- ¿El paralelismo realmente aporta (es API externa) o solo es legibilidad?
- ¿Cómo voy a verificar que funciona en producción?
Si dudas en 2+, considera secuencial.
Resumen
- 8 anti-patterns: race conditions, merge sin modo claro, paralelismo aparente, Wait colgado, keys no comparables, rate limit compartido, efectos lateralizados, sobre-paralelo
- Checklist antes de fan-out: independencia, rate limits, error handling, sincronización
- Default conservador: secuencial es más simple. Paralelismo solo cuando vale la pena.
Lo que sigue: Mini-proyecto integrador — 3 fuentes paralelas a reporte único.
Creado: Mayo 11, 2026 Versión: 1.0