Fan-Out Condicional

Descripción de la cápsula

Hasta acá el fan-out era incondicional — todas las ramas se ejecutan siempre. Pero a veces quieres ejecutar solo algunas ramas según el input: "si el lead es enterprise, llamar API premium; si es regular, solo Slack". Es fan-out condicional.

En esta cápsula vas a aprender los 3 patterns de fan-out condicional: con IF + ramas, con Switch + ramas convergentes, y combinación de ambos. Cada uno tiene su lugar.

---

Lo que vas a aprender

• ✅ Implementar fan-out con activación condicional por rama
• ✅ Diferenciar los 3 patterns
• ✅ Combinar con Merge cuando las ramas vuelven a converger
• ✅ Aplicar a casos reales

---

Pattern 1: IF + ramas paralelas

[Input]
   │
[IF: condición]
├─ TRUE → [rama A: hace cosas]
│          [rama B: otras cosas]
│
└─ FALSE → [rama C]

Si TRUE, ejecuta múltiples cosas en paralelo. Si FALSE, solo C.

Caso típico: "Si el lead es VIP, mandar email Y notificar Slack Y crear ticket en CRM. Si no es VIP, solo agregar a Sheet."

---

Pattern 2: Switch + ramas paralelas dentro de cada rama

[Input]
   │
[Switch: category]
├─→ "enterprise" → [rama A] [rama B] [rama C]
├─→ "smb"        → [rama D] [rama E]
└─→ "free"       → [rama F]

Cada salida del Switch puede tener fan-out propio. Las ramas dentro de una salida son paralelas; entre salidas son alternativas.

---

Pattern 3: Fan-out completo + convergencia condicional

[Input]
   │
   ├─→ [Set: aplicar a A]
   ├─→ [Set: aplicar a B]
   └─→ [Set: aplicar a C]
        │
        ▼
   [Merge: condicional]

Difícil — Merge no tiene "condicional" nativo. Workaround: cada rama produce items con flag, después Filter después del Merge.

---

Caso real: notificación según severidad

[Webhook: ticket]
   │
[Set: severity]
   │
[Switch: severity]
├─→ "critical" → [Slack]
│              + [SMS]
│              + [Email a oncall]
│              + [PagerDuty alert]
│
├─→ "high"     → [Slack]
│              + [Email a equipo]
│
├─→ "medium"   → [Slack]
│
└─→ "low"      → [Sheet: append cola]

Críticas notifican por 4 canales paralelos. Altas por 2. Medias 1. Bajas, log.

---

Trampas comunes

Trampa 1: Lógica duplicada entre ramas del Switch

Qué pasa: Las salidas "critica" y "alta" tienen 80% de las mismas ramas. Cambias algo, debes actualizar en 2 lados.

Cómo evitar:

• Extraer la lógica común ANTES del Switch
• Switch solo para lo que realmente difiere

---

Trampa 2: Fan-out sin pensar en idempotencia

Qué pasa: 4 ramas paralelas modifican el mismo CRM. Race conditions, updates perdidos.

Cómo evitar:

• Una rama actualiza el CRM, otras notifican o leen
• O usar locking si tu sistema lo soporta

---

Trampa 3: Demasiados puntos de salida

Qué pasa: Tu workflow tiene 8 destinos finales (Slack 1, Slack 2, Email A, Email B, Sheet X, Sheet Y, CRM, alert PD). Imposible ver el panorama.

Cómo evitar:

• Agrupar destinos por tipo en sub-workflows
• Convergir antes de los destinos para reducir el spaghetti

---

Resumen y siguiente paso

• Fan-out condicional: ramas paralelas que se activan según condiciones
• 3 patterns: IF + ramas, Switch con ramas paralelas por salida, fan-out + Merge condicional
• Caso típico: notificación según severidad/categoría
• 3 trampas: lógica duplicada, sin pensar idempotencia, demasiados destinos

Lo que sigue: Anti-patterns generales del módulo — qué evitar en cualquier diseño con paralelismo.

---

Creado: Mayo 11, 2026 Versión: 1.0