Módulo 6: Manejo de Errores
Diseño Defensivo
Descripción de la cápsula
Las cápsulas anteriores enseñaron a reaccionar a errores. Diseño defensivo es anticiparlos durante el design — pensar "¿qué puede fallar?" antes de implementar, y construir el workflow para que cuando falle, falle de la mejor manera posible.
Es la diferencia entre workflows que trabajan en condiciones perfectas (todo el tiempo en testing pero rompen en producción) y workflows production-ready desde el día 1.
Lo que vas a aprender
- ✅ Checklist de preguntas defensivas durante design
- ✅ Patterns preventivos (validación, idempotencia, tracking)
- ✅ Anti-patterns que parecen razonables pero rompen en producción
Las 7 preguntas defensivas
Antes de implementar un workflow, hazte estas 7 preguntas:
Pregunta 1: ¿Qué pasa si el trigger no se dispara?
- Schedule sin ejecutar (server n8n caído)
- Webhook sin recibir (servicio externo down)
- Manual sin que alguien lo dispare
Plan B: monitoring activo. Si workflow no ejecuta en X tiempo esperado, alert.
Pregunta 2: ¿Qué pasa si el trigger se dispara N veces?
- Webhook duplicado por el servicio
- Schedule que solapan en DST
- Manual + automático al mismo tiempo
Plan B: idempotencia. Workflow debe ser safe to run multiple times sin causar duplicados.
Pregunta 3: ¿Qué pasa si los datos son distintos a lo esperado?
- Campo faltante
- Tipo distinto
- Volumen inesperado (1000 items vs 10)
- Caracteres especiales / encoding
Plan B: validación al inicio. Set + IF defensivo.
Pregunta 4: ¿Qué pasa si una API externa falla?
- Cada API que llamas → ¿retry? ¿fallback? ¿skip?
Plan B: retry + fallback + Continue on Fail según criticidad.
Pregunta 5: ¿Qué pasa si el workflow tarda más de lo esperado?
- Timeout
- Solapamiento con siguiente ejecución
- Memoria saturada
Plan B: estimar peor caso, configurar timeouts, dividir en batches.
Pregunta 6: ¿Qué pasa si necesito debuggear esto en 3 meses?
- ¿Hay logs?
- ¿Sticky notes documentando el "por qué"?
- ¿Convenciones de nombres claras?
Plan B: documentar mientras construyes.
Pregunta 7: ¿Qué pasa si alguien más mantiene este workflow?
- ¿Pueden entenderlo sin tu ayuda?
- ¿Convenciones consistentes con otros workflows?
Plan B: convenciones organizacionales, code review (mental).
Patrones defensivos
Pattern 1: Idempotencia
Workflow safe to run multiple times sin causar daño.
Implementación:
- Check antes de crear: "¿este registro ya existe?"
- Idempotency keys en APIs que lo soportan
- INSERT IF NOT EXISTS en lugar de INSERT
Pattern 2: Validation at boundary
Validar al recibir datos (trigger), no más adentro.
[Trigger]
│
[Set: validar — is_valid]
│
[IF: is_valid]
├─ TRUE → resto del workflow asume datos OK
└─ FALSE → log + skip
Después de la validación, el resto del workflow puede asumir datos válidos. Sin verificaciones duplicadas.
Pattern 3: Single source of truth
Un solo lugar define el estado verdadero. Si tienes:
- Sheet de leads
- CRM con leads
- Cache local de leads
Cuál es la fuente real? Decidir y documentar.
Pattern 4: Tracking and observability
Loggear ejecuciones para análisis:
- Sheet con cada run: timestamp, status, items procesados, errores
- Métricas: tasa de éxito, latencia, volumen
Sin observabilidad, debugging es adivinar.
Pattern 5: Limit blast radius
Si algo falla, limitar el daño:
- Procesar en batches pequeños
- Failover automático no debería afectar otros workflows
- Test changes en staging antes de prod
Anti-patrones defensivos
Anti-pattern 1: "Optimistic" workflow
[Trigger] → [HTTP] → [Procesar] → [Save]
Asume que todo funciona. Sin Continue on Fail, sin retry, sin Error Workflow. Funciona el 99% del tiempo. El 1% que falla, no notas.
Fix: agregar defensa apropiada en cada nodo crítico.
Anti-pattern 2: Over-engineering
Aplicar todo el módulo a todos los workflows:
- Retry en cada nodo
- Continue on Fail en cada nodo
- Error Workflow + fallback + cache + queue + ...
Workflow simple se vuelve imposible de mantener.
Fix: balance. Defensa proporcional a la criticidad.
Anti-pattern 3: Defensa solo en el "happy path"
Diseñas el workflow funcional. Tests pasan. Implementas error handling después como afterthought.
Resultado: error handling fragmentado, inconsistente, con gaps.
Fix: error handling es parte del design, no add-on.
Anti-pattern 4: Asumir que "esto nunca pasa"
"La API nunca falla así." "El cliente nunca mandaría ese dato." 6 meses después: pasó.
Fix: asumir que todo puede pasar. Validar todo. Manejar todo.
Checklist al diseñar un workflow nuevo
Antes de implementar:
- Trigger: ¿qué pasa si dispara N veces? ¿0 veces?
- Datos: ¿qué validaciones necesito?
- APIs externas: ¿retry? ¿fallback?
- Operaciones críticas: ¿idempotentes?
- Volumen: ¿qué pasa con 10× el volumen esperado?
- Errores: ¿quién se entera si falla?
- Mantenimiento: ¿hay sticky notes?
- Test: ¿cómo lo voy a testear?
Si todas marcadas, estás listo para implementar.
Ejemplo: aplicar checklist a un workflow
Caso: workflow que recibe registros vía webhook y los crea en CRM.
| Pregunta | Decisión |
|---|---|
| Trigger N veces | Idempotencia: check email exists en CRM antes de crear |
| Validación | Set + IF al inicio: email válido, nombre presente |
| API CRM | Retry 3 con backoff, Continue on Fail; fallback a Sheet queue |
| Operación crítica | CRM API tiene idempotency key — usar |
| Volumen | Si > 100/min, alerta (probablemente DDoS) |
| Errores | Error Workflow + Slack |
| Mantenimiento | Sticky Notes explicando decisiones de diseño |
| Test | Test con datos válidos, inválidos, duplicados, alta volumen |
Después de este checklist, implementas con confianza.
Resumen
- Diseño defensivo: anticipar fallos durante design, no después
- 7 preguntas a hacerse antes de implementar
- 5 patterns: idempotencia, validation at boundary, single source of truth, observability, limit blast radius
- 4 anti-patterns: optimistic, over-engineering, defensa tardía, asumir "no pasa"
- Checklist de 8 puntos antes de implementar
Lo que sigue: Mini-proyecto integrador — workflow resiliente con todo lo del módulo.
Creado: Mayo 11, 2026 Versión: 1.0