Módulo 6: Reintentos, alertas y recuperación

1. Introducción: reintentar, alertar, recuperar

Descripción

Al terminar esta lección vas a poder describir, con nombre propio, las cinco piezas que convierten un sistema de automatización que funciona en uno que sobrevive: reintentos que no duplican, acciones compensatorias que deshacen lo que quedó a medias, alertas que suenan solo cuando de verdad importa, un error workflow con una cola de mensajes muertos que no pierde nada, y un motor de replay que convierte un bug intermitente en uno reproducible. Vas a tener el mapa completo de las ocho lecciones de este módulo —que es el último de la guía— y vas a ver cómo cada una se apoya en lo que ya construiste en los módulos anteriores. Y vas a reencontrarte con el sistema multi-workflow de Cumbre que vas a volver resiliente de aquí al capstone.

Esto importa por una razón concreta. Hasta aquí aprendiste a que un efecto no se duplique (Módulo 2), a que dos workflows se hablen con un contrato estable (Módulo 3), a guardar la verdad del sistema en un ledger de Postgres (Módulo 4) y a coordinar varios workflows con el patrón outbox (Módulo 5). Cada una de esas piezas asume que las cosas salen bien. Este módulo es el que se ocupa de cuando no salen bien: cuando la API de crédito se cae a media ejecución, cuando el webhook dispara dos veces, cuando un cobro se hizo pero el registro no, cuando un item falla después de tres reintentos y hay que decidir si lo pierdes o lo apartas. La confiabilidad no es una pieza más; es lo que amarra todas las anteriores.

Conexión con el módulo: esta lección no te va a enseñar todavía a configurar un reintento ni un error workflow. Es el mapa. Aquí ves el problema completo —qué le falta al sistema de Cumbre para ser confiable—, conoces las cinco herramientas que lo resuelven, y recibes el recorrido de las siete lecciones que siguen. La lección 2 arranca con los reintentos seguros; la 3 con las acciones compensatorias; la 4 con la decisión de dónde alertar; la 5 con los error workflows y la cola de mensajes muertos; la 6 con el replay para reproducir un duplicado; la 7 traza la frontera exacta entre lo que resuelve esta guía y lo que resuelve la guía de producción; y la 8 es el capstone que junta todo en un entregable defendible en entrevista. Una nota de límite desde ya: este módulo no te enseña a operar el sistema en producción —dashboards, backups, escalado, equipos—. Eso es otra guía, y la lección 7 dice exactamente dónde está la línea.

De un sistema que funciona a un sistema que sobrevive

Piensa en dos panaderías que hacen exactamente el mismo pan. La masa es idéntica, el horno es el mismo, la receta se sigue al pie de la letra. Un día cualquiera, con todo en orden, las dos entregan un pan impecable y nadie notaría la diferencia.

La diferencia aparece el día que algo se rompe. Se va la luz veinte minutos a media hornada. Un proveedor manda harina con menos gluten. Un empleado nuevo mete dos veces la misma bandeja al horno sin darse cuenta. Una de las dos panaderías tiene una respuesta para cada una de esas cosas: un generador que arranca solo, una prueba rápida de la harina antes de amasar, una marca en la bandeja que ya entró. La otra no tiene ninguna, y ese día el pan sale mal —o salen dos panes cobrados como uno, o no sale nada— y el cliente se entera.

Las dos panaderías hacen el mismo pan cuando todo va bien. Solo una sigue haciendo buen pan cuando algo va mal.

Eso es exactamente lo que separa un workflow que funciona de un sistema que es confiable. Todo lo que construiste hasta el Módulo 5 es la receta: idempotencia, contratos, ledger, outbox. Con eso, cuando cada evento entra una sola vez, cada API responde a tiempo y cada nodo hace su parte, el sistema de Cumbre procesa pedidos de maravilla. Este módulo es el generador, la prueba de harina y la marca en la bandeja: lo que hace que el sistema siga entregando buen resultado cuando —no si, cuando— algo falle.

Y aquí está el matiz honesto, porque este módulo no es una promesa de que nada va a fallar. Es lo contrario: parte de aceptar que todo va a fallar tarde o temprano, y se ocupa de que cuando eso pase, el sistema no duplique un cobro, no despierte a nadie por una tontería, no pierda un pedido en silencio, y te deje reconstruir qué pasó. Un sistema confiable no es uno que no falla. Es uno que falla bien.

El sistema de Cumbre, tal como quedó al terminar el Módulo 5

Vale la pena reencontrarnos con el caso, porque de aquí al capstone es el mismo. Si vienes de las guías anteriores del ecosistema ya conoces a Cumbre: una distribuidora mayorista latinoamericana que le vende café, té e insumos a unas 400 cafeterías y tiendas pequeñas. Es chica —doce personas— y por eso automatiza: no le alcanza el equipo para procesar los pedidos a mano.

En esta guía, Cumbre no tiene un workflow. Tiene un sistema de cuatro workflows que se coordinan cada vez que entra un pedido. Cada uno es un sub-workflow con su propio contrato (Módulo 3), y los cuatro comparten el ledger de Postgres del Módulo 4:

Workflow	Qué hace	Qué tipo de efecto tiene
`order-triage`	Recibe el evento del webhook, deduplica contra el ledger, valida el pedido contra su contrato y decide a quién despachar el trabajo	Lecturas y decisiones (idempotente por diseño)
`check-credit`	Coloca una retención de crédito por el monto del pedido contra la línea de crédito del cliente y responde aprobado o rechazado	Efecto real: crea un `credit_hold`
`inventory-sync`	Reserva el inventario de cada línea del pedido con un upsert idempotente	Efecto real: reserva stock (upsert idempotente, Módulo 2)
`issue-refund`	Libera una retención de crédito o devuelve dinero cuando un pedido se cae o se cancela después de haber cobrado	Efecto real: crea un `refund` con `Idempotency-Key`

Fíjate en la columna de la derecha, porque es la que va a organizar todo el módulo. order-triage casi no tiene efectos: lee, decide, escribe en el ledger. Los otros tres crean cosas en el mundo: una retención de crédito, una reserva de inventario, un reembolso. Y las cosas que se crean en el mundo son exactamente las que se pueden duplicar, las que hay que poder deshacer, y las que merecen una alerta cuando fallan. La distinción entre leer y tener efecto que viste en el Módulo 1 vuelve aquí convertida en el criterio central del módulo.

Este es el grafo de dependencias del sistema, tal como quedó al final del Módulo 5:

                 webhook (a veces dispara 2 veces)
                          │
                          ▼
                   ┌─────────────┐
                   │ order-triage│  dedup contra run_ledger + valida contrato
                   └──────┬──────┘
                          │ escribe intents en la tabla outbox
              ┌───────────┼───────────┐
              ▼           ▼           ▼
       ┌────────────┐ ┌──────────┐ ┌──────────────┐
       │check-credit│ │inventory-│ │  (otros       │
       │            │ │  sync    │ │   consumidores)│
       └─────┬──────┘ └────┬─────┘ └──────────────┘
             │             │
             │  si algo se cae a medias
             ▼             ▼
          ┌──────────────────┐
          │   issue-refund   │  compensación: deshace lo hecho
          └──────────────────┘

No necesitas recordar cada flecha de memoria. Lo único que importa por ahora es la forma: un weblook poco confiable que a veces dispara dos veces, un order-triage que absorbe ese ruido con el ledger, un fan-out a los workflows que tienen efectos, y un issue-refund que entra en escena cuando algo hecho hay que deshacerlo.

Este sistema, hoy, funciona. Lo que le falta es todo lo que pasa cuando algo se rompe. Eso es lo que le vamos a agregar.

Las cinco piezas de la resiliencia

Vamos a nombrar las cinco herramientas que forman este módulo, cada una con una frase de qué resuelve y en qué lección vive. Piénsalo como los cinco instrumentos que le faltan al sistema de Cumbre para pasar de funcionar a sobrevivir.

Pieza 1 — Reintentos seguros (lección 2). Cuando la API de crédito no responde por un segundo, no quieres que el pedido se caiga: quieres que n8n lo intente de nuevo. Pero un reintento re-ejecuta el efecto, y ahí está la trampa: reintentar un issue-refund sin cuidado emite dos reembolsos. La regla que vas a aprender es exacta: un reintento solo es seguro si el paso es idempotente. La idempotencia del Módulo 2 no era un lujo teórico; es lo que hace que activar los reintentos de n8n no duplique nada.

Pieza 2 — Acciones compensatorias (lección 3). A veces no puedes hacer todo de una sola vez y de forma atómica. check-credit coloca la retención, e inventory-sync, un paso después, descubre que no hay stock. La retención ya se hizo. No puedes viajar al pasado para no hacerla. Lo que haces es deshacerla: emites la liberación con issue-refund. Por cada acción que crea algo hay una acción que lo anula. Es el "deshacer" de los sistemas distribuidos, y vas a ver por qué un rollback perfecto casi nunca existe.

Pieza 3 — Dónde alertar (lección 4). No todo fallo merece despertar a alguien a las 3 de la mañana. Un timeout de la API de crédito que se resuelve solo en el segundo intento no es una emergencia; es ruido. Un issue-refund que falló tres veces seguidas y dejó dinero en el limbo, sí lo es. La habilidad es distinguir la señal del ruido: qué fallo es transitorio y se cura solo, y cuál necesita un humano. Si alertas de todo, nadie mira las alertas —eso se llama fatiga de alertas, y mata más sistemas que los propios fallos—.

Pieza 4 — Error workflows y cola de mensajes muertos (lección 5). n8n tiene un nodo, el Error Trigger, que se dispara cuando otro workflow falla y te entrega los detalles del fallo. Con él armas un error workflow central: un solo lugar que captura cualquier fallo del sistema. Y cuando un item falla después de agotar todos sus reintentos, no lo pierdes: lo apartas en una cola de mensajes muertos —una tabla dead_letter en el mismo Postgres del Módulo 4— para revisarlo y reprocesarlo después, con todo su contexto guardado.

Pieza 5 — El replay (lección 6). El peor bug es el que aparece una de cada cien veces y desaparece cuando lo buscas. "A veces Cumbre emite dos reembolsos." ¿Cuándo? ¿Por qué? n8n 2.0 tiene un motor de depuración que te deja cargar los datos de una ejecución real que ya pasó y volver a correrla paso a paso, siguiendo la clave de idempotencia por cada nodo hasta ver exactamente dónde se creó el segundo efecto. Convierte un bug intermitente y frustrante en uno reproducible y arreglable.

Cinco piezas. Cada una tapa un modo de falla distinto del sistema, y juntas son lo que separa a un constructor de workflows de alguien que es dueño de un sistema de automatización.

Ejemplo trabajado: el mismo pedido, con y sin resiliencia

Veamos la diferencia en concreto, sin entrar todavía en cómo se configura cada cosa. Toma un pedido de Cumbre que entra por el webhook:

{
  "order_id": "ORD-3180",
  "customer_id": "CUST-118",
  "customer_name": "Luna Coffee",
  "channel": "web",
  "amount": 4820,
  "currency": "MXN",
  "line_items": [
    { "sku": "CF-ARA-500", "quantity": 20, "unit_price": 148.5 },
    { "sku": "TE-CHM-100", "quantity": 30, "unit_price": 62 }
  ]
}

Cómo se comporta el sistema de hoy —el que solo funciona— frente a tres tropiezos reales:

Tropiezo 1: el webhook dispara dos veces. El sistema del Módulo 5 ya está protegido: order-triage deduplica contra el ledger y el segundo disparo no hace nada. Bien. Esa pieza ya la tienes.

Tropiezo 2: la API de crédito tarda tres segundos de más y da timeout. El sistema de hoy no reintenta. El pedido ORD-3180 se cae con un error, y nadie se entera hasta que Luna Coffee llama preguntando por qué su pedido no salió. Falta la pieza 1.

Tropiezo 3: check-credit colocó la retención de 4820 pesos, y un segundo después inventory-sync descubre que no hay 20 kilos de café arábica. El sistema de hoy deja la retención puesta: Luna Coffee tiene 4820 pesos bloqueados de su línea de crédito por un pedido que nunca se va a surtir. Falta la pieza 2.

Cómo se comporta el mismo pedido en el sistema resiliente que vas a construir:

Tropiezo 2 se resuelve solo: n8n reintenta check-credit dos veces con una pequeña espera, la API responde en el segundo intento, y el pedido sigue su curso. Nadie se enteró porque no había nada de qué enterarse (pieza 1 + pieza 3: el fallo transitorio no alerta).

Tropiezo 3 dispara una compensación: al fallar inventory-sync, el sistema emite un issue-refund que libera los 4820 pesos, escribe el fallo en la cola de mensajes muertos con todo el contexto, y —como es un fallo que involucra dinero y stock— manda una alerta al dueño de operaciones para que decida qué hacer con el pedido (piezas 2, 4 y 5).

Mismo pedido. Mismos tropiezos. La diferencia entera es este módulo.

Qué esperar de esa comparación. No es que el sistema resiliente sea "más grande" o tenga más nodos por el gusto de tenerlos. Es que cada tropiezo tiene una respuesta diseñada, en vez de terminar en un error silencioso o en un efecto duplicado. Esa es toda la diferencia, y es exactamente la clase de cosa que te preguntan en una entrevista técnica: "¿qué pasa si la API se cae a media ejecución?". Al terminar este módulo, tienes la respuesta para cada uno de esos "¿qué pasa si?".

Correctitud contra operación: la frontera que este módulo respeta

Hay una distinción que conviene sembrar desde la primera lección, porque organiza todo lo que sigue y es el tema entero de la lección 7.

Esta guía —las seis unidades— te enseña a diseñar la correctitud de un sistema: que sea idempotente, que tenga contratos, que deduplique, que reintente sin duplicar, que compense, que alerte bien, que no pierda items. Es el trabajo de diseño: decidir cómo debe comportarse el sistema para ser confiable.

Hay otro trabajo, distinto, que es operar el sistema en producción: montar dashboards de monitoreo, hacer backups, escalar la infraestructura cuando el volumen crece, guardar los secretos en un gestor externo, versionar los workflows con Git, coordinar a un equipo que edita los mismos flujos. Ese trabajo es real y es importante, y no es esta guía. Vive en n8n-production-maintenance-guide.

La panadería otra vez: diseñar la correctitud es diseñar la receta y el proceso para que el pan salga bien incluso cuando algo se rompe. Operar es administrar la panadería día a día —los turnos, las compras, la contabilidad, abrir una segunda sucursal—. Las dos cosas importan. Son trabajos distintos.

Digo esto ahora por honestidad y por foco: cuando en la lección 5 montes la cola de mensajes muertos, no vas a montar un dashboard bonito para verla —eso es operación—; vas a montar la tabla que no pierde el item, que es correctitud. La lección 7 declara la línea completa, con una tabla de qué resuelve la Community self-hosted a costo cero y qué exige pagar. Por ahora, quédate con la frase: esta guía diseña que el sistema sea correcto; la otra lo opera.

El mapa de este módulo

Lección	Qué resuelve
2	Reintentos seguros: el setting Retry On Fail de n8n 2.0, por qué un reintento re-ejecuta el efecto, y la regla de que solo es seguro reintentar lo que es idempotente
3	Acciones compensatorias: cuando no puedes evitar repetir un efecto, lo deshaces; el patrón "por cada crear, un anular" y por qué el rollback perfecto casi no existe
4	Dónde deben alertar los fallos: señal contra ruido, fatiga de alertas, qué es un fallo "real" para cada workflow y quién es el dueño que responde
5	Error workflows y cola de mensajes muertos: el nodo Error Trigger como error workflow central, y la tabla `dead_letter` que no pierde el item que falló tras todos los reintentos
6	Reproducir un bug de duplicado con el replay: cargar una ejecución real, seguir la clave de idempotencia paso a paso y ver dónde se creó el segundo efecto
7	La frontera con producción y equipos: qué resuelve Community a $0, qué exige Cloud/Enterprise, y por qué el resto vive en la guía de producción
8	Capstone: el sistema multi-workflow confiable de Cumbre de punta a punta, con criterios de evaluación y las decisiones de diseño argumentadas

Fíjate en el orden, porque tiene una lógica. Primero las dos respuestas al fallo de un efecto: reintentar (2) cuando puedes repetir sin daño, y compensar (3) cuando no. Después la decisión humana: dónde alertar (4). Después la infraestructura de captura: el error workflow y la cola de mensajes muertos (5). Después la herramienta de diagnóstico: el replay (6). Después la frontera honesta con producción (7). Y al final, el capstone que integra las seis anteriores (8).

Si te sirve una imagen: las lecciones 2 y 3 son cómo reaccionar a un fallo, la 4 es a quién avisar, la 5 es dónde guardar lo que no se pudo procesar, la 6 es cómo entender qué pasó, y la 7 es hasta dónde llega tu responsabilidad en esta guía. El capstone las hace trabajar juntas sobre el sistema de Cumbre.

Lo que este módulo deliberadamente no cubre

Vale la pena decirlo temprano para que sepas dónde buscar lo que no está aquí.

No es la guía de operación en producción. Dashboards de monitoreo, alertas conectadas a herramientas externas de observabilidad, backups del ledger, escalado con queue mode a varias máquinas, gestión de secretos externos, entornos de staging, Git y trabajo en equipo: todo eso es n8n-production-maintenance-guide. Aquí diseñas la correctitud; allá se opera. La lección 7 traza la línea con precisión.

No es un curso de teoría de sistemas distribuidos. Vas a usar ideas que vienen de ahí —idempotencia, compensación, colas de mensajes muertos, el patrón saga— pero en su forma práctica dentro de n8n, no en su formalismo académico. Si después quieres la teoría completa, es otro camino y es válido; no es este.

No reemplaza los módulos anteriores. Este módulo asume que ya dominas la idempotencia (Módulo 2), los contratos (Módulo 3), el ledger de dedup (Módulo 4) y la coordinación con outbox (Módulo 5). No los vuelve a explicar; los usa. Si al leer una lección sientes que se apoya en algo que no recuerdas bien, ese es el número de módulo al que conviene volver un momento.

Errores comunes

Creer que reintentar es gratis (conceptual). Qué pasa: alguien descubre el setting Retry On Fail de n8n, lo activa en todos los nodos "por si acaso", y semanas después Cumbre emite reembolsos dobles sin explicación. Por qué pasa: es tentador tratar el reintento como una red de seguridad universal, porque en las lecturas —consultar un dato— efectivamente lo es. El problema es que en los efectos —crear un reembolso, cobrar— un reintento no repite una consulta inofensiva: repite la creación. Cómo detectarlo: revisa si tienes reintentos activados en nodos que crean algo sin una clave de idempotencia que los proteja. Cómo corregirlo: la regla de la lección 2 —reintenta solo lo idempotente— y, para lo que no puedes hacer idempotente, la compensación de la lección 3. Reintentar no es gratis; es seguro solo bajo una condición precisa.

Alertar de todos los fallos (conceptual). Qué pasa: se conecta cada error del sistema a una notificación, con la buena intención de "no perderse nada". A las dos semanas llegan cuarenta alertas al día, casi todas de fallos transitorios que se resolvieron solos, y el equipo empieza a ignorarlas. El día que llega la alerta que sí importaba —un reembolso atascado— nadie la mira, porque está enterrada entre el ruido. Por qué pasa: distinguir señal de ruido requiere una decisión de diseño que da trabajo, y conectar todo a una notificación es más fácil. Cómo detectarlo: si tu canal de alertas recibe más de un puñado de mensajes al día y la mayoría no requieren que nadie haga nada, tienes fatiga de alertas en camino. Cómo corregirlo: la lección 4, que te enseña a definir qué es un fallo "real" para cada workflow antes de conectar la primera alerta.

Suponer que un rollback deshace todo perfectamente (conceptual). Qué pasa: alguien diseña la compensación pensando que "deshacer" devuelve el sistema a un estado como si nada hubiera pasado, y se sorprende cuando el cliente ya recibió un correo de confirmación de un pedido que después se canceló. Por qué pasa: la palabra "rollback" viene de las bases de datos, donde una transacción abortada efectivamente no deja rastro. En un sistema de integración con efectos externos —correos enviados, cobros hechos, mensajes mandados— eso casi nunca es cierto: hay efectos que ya salieron al mundo y no se pueden retirar. Cómo detectarlo: para cada efecto de tu sistema, pregúntate "si tuviera que deshacer esto, ¿quedaría rastro?". Cómo corregirlo: la lección 3 te enseña a diseñar compensaciones realistas —que dejan el sistema en un estado aceptable, no idéntico— y a saber qué efectos conviene retrasar justamente para poder compensarlos limpio.

Ejercicios

Ejercicio 1 — Clasifica los efectos del sistema. Toma los cuatro workflows de Cumbre (order-triage, check-credit, inventory-sync, issue-refund). Para cada uno, escribe en una frase: (a) qué efecto tiene en el mundo, si es que tiene alguno, y (b) si ese efecto se puede duplicar de forma peligrosa cuando el workflow corre dos veces.

Ver solución

order-triage: (a) casi no tiene efectos externos; lee el evento, deduplica contra el ledger, valida el contrato y decide el despacho. (b) No es peligroso repetirlo, porque su trabajo principal —deduplicar— está diseñado para absorber disparos repetidos; correrlo dos veces con el mismo order_id termina en la misma decisión y no crea un segundo registro.

check-credit: (a) crea una retención de crédito (credit_hold) por el monto del pedido. (b) Sí es peligroso repetirlo sin protección: dos corridas podrían colocar dos retenciones y bloquear el doble del monto en la línea de crédito del cliente. Necesita una clave de idempotencia o una escritura condicional (Módulo 2).

inventory-sync: (a) reserva stock de cada línea. (b) Depende de cómo esté escrita la reserva: si es un upsert idempotente por order_id (Módulo 2), repetirlo es inofensivo; si es un decremento ciego ("réstale 20 al stock"), repetirlo resta 40 y sí es peligroso. Esta diferencia es exactamente por qué el Módulo 2 insistía en upserts sobre decrementos.

issue-refund: (a) crea un reembolso o libera una retención. (b) Es el más peligroso de repetir: dos reembolsos es dinero que sale dos veces. Es el caso de libro para una clave de idempotencia (Idempotency-Key), y por eso va a ser el protagonista del replay de la lección 6.

Por qué funciona: este ejercicio instala el reflejo central del módulo. Antes de decidir si un workflow puede reintentarse, compensarse o alertar, la primera pregunta es siempre "¿qué efecto tiene y se puede duplicar?". Los que no tienen efectos peligrosos casi no dan problemas; los que sí, son el trabajo entero de este módulo.

Ejercicio 2 — Empareja el tropiezo con la pieza. Para cada uno de estos cinco tropiezos de Cumbre, di cuál de las cinco piezas del módulo lo resuelve, y en qué lección se ve:

(a) La API de crédito da timeout una vez y responde bien al reintentar. (b) Se colocó una retención de crédito pero el pedido no se pudo surtir, y hay que soltarla. (c) Un pedido falló después de tres reintentos y no queremos perderlo. (d) "A veces salen dos reembolsos" y no sabemos cuándo ni por qué. (e) Llegan cuarenta notificaciones al día y nadie las mira.

Ver solución

(a) Reintentos seguros (pieza 1, lección 2). Es un fallo transitorio; el reintento lo cura solo. La condición para que sea seguro es que check-credit esté protegido para no colocar dos retenciones si el timeout ocurrió después de que la retención se hizo.

(b) Acciones compensatorias (pieza 2, lección 3). La retención ya se hizo y no se puede "no hacer"; se deshace con un issue-refund que la libera.

(c) Cola de mensajes muertos (pieza 4, lección 5). Tras agotar los reintentos, el item se aparta en la tabla dead_letter con su contexto, para reprocesarlo a mano después.

(d) El replay (pieza 5, lección 6). Cargas la ejecución real que produjo el duplicado y la sigues paso a paso hasta ver dónde se creó el segundo efecto.

(e) Dónde alertar (pieza 3, lección 4). Es fatiga de alertas: se está notificando de fallos que no requieren acción humana. La solución es definir qué es un fallo "real" para cada workflow y alertar solo de esos.

Por qué funciona: si pudiste emparejar los cinco, ya tienes internalizado el mapa del módulo. Cada tropiezo real de un sistema cae en una de estas cinco categorías, y saber en cuál cae es el primer paso para resolverlo.

Ejercicio 3 — Traza la frontera. Sin volver a leer la sección correspondiente, clasifica cada una de estas seis tareas como "correctitud (esta guía)" o "operación (la guía de producción)":

(a) Decidir que un issue-refund fallido debe alertar y un timeout de crédito no. (b) Montar un dashboard con gráficas del volumen de pedidos por hora. (c) Diseñar la tabla dead_letter para no perder items. (d) Configurar backups automáticos del Postgres del ledger. (e) Guardar el token de la API de pagos en un gestor de secretos externo. (f) Escribir la clave de idempotencia con la que un reembolso no se duplica.

Ver solución

(a) Correctitud. Es una decisión de diseño sobre cómo debe comportarse el sistema ante un fallo. Lección 4.

(b) Operación. Un dashboard de monitoreo es una herramienta para ver el sistema funcionando, no para que sea correcto. Guía de producción.

(d) Operación. Los backups protegen el dato ya escrito contra pérdida física; son parte de administrar la infraestructura, no de diseñar la lógica. Guía de producción.

(e) Operación. Dónde y cómo se guardan los secretos es infraestructura y seguridad operativa. Esta guía usa las credenciales de n8n; el gestor externo es de la guía de producción. Lección 7 explica exactamente esta frontera.

(f) Correctitud. La clave de idempotencia es el corazón del diseño que evita duplicados. Módulo 2, y se usa en todo este módulo.

Por qué funciona: la línea entre correctitud y operación es la que la lección 7 declara formalmente, y saber de qué lado cae cada tarea es lo que te evita, en un proyecto real, meterte a montar infraestructura de producción cuando el problema era de diseño —o al revés—. Si dudaste en alguna, la pregunta que desempata es: "¿esto cambia cómo se comporta el sistema, o solo cómo lo veo y lo mantengo?". Lo primero es correctitud; lo segundo, operación.

Resumen y siguiente paso

En esta lección viste que la diferencia entre un sistema que funciona y uno confiable no es la receta —esa ya la tienes de los Módulos 2 a 5— sino lo que pasa cuando algo se rompe, con la imagen de las dos panaderías que hacen el mismo pan y solo una sigue haciéndolo bien el día malo. Reencontraste el sistema de cuatro workflows de Cumbre —order-triage, check-credit, inventory-sync, issue-refund— y su grafo de dependencias, y viste que la columna que importa es qué efecto tiene cada workflow, porque los efectos son lo que se duplica, lo que hay que deshacer y lo que merece alerta. Conociste las cinco piezas de la resiliencia: reintentos seguros, acciones compensatorias, dónde alertar, error workflows con cola de mensajes muertos, y el replay. Y sembraste la frontera que la lección 7 va a declarar en firme: esta guía diseña que el sistema sea correcto, y la guía de producción lo opera.

Antes de avanzar a la lección 2 deberías poder: nombrar las cinco piezas del módulo y qué resuelve cada una; explicar por qué un reintento no es gratis en un workflow que tiene efectos; y decir de memoria los cuatro workflows del sistema de Cumbre y cuál de ellos es el más peligroso de duplicar.

Lo que no viste todavía —y es lo primero que vamos a construir— es cómo se configura un reintento en n8n 2.0, y por qué la regla no es "reintenta cuando algo falle" sino "reintenta solo cuando repetir el efecto sea seguro". La lección 2 arranca justo ahí: el setting Retry On Fail, qué pasa exactamente cuando un nodo se reintenta, y por qué la idempotencia que aprendiste en el Módulo 2 es la condición que separa un reintento que te salva de uno que te duplica un cobro.

Recursos

Error handling — n8n Docs — la página que reúne los mecanismos de manejo de errores que vas a estudiar en las lecciones 2, 4 y 5: reintentos, el Error Trigger y los error workflows.
Handle errors gracefully — n8n Docs — guía oficial sobre cómo diseñar el manejo de errores de un workflow, base conceptual de todo este módulo.
Release notes 2.x — n8n Docs — el historial de la versión 2, publicada el 5 de diciembre de 2025, para confirmar qué versión estás usando frente a lo que dice esta guía.
Self-hosted AI Starter Kit — n8n — el kit que trae Postgres y con el que corres todos los laboratorios de esta guía a costo cero, incluido el ledger y la cola de mensajes muertos.

← Anterior8. Proyecto: coordinar tres workflows dependientes Siguiente →2. Reintentos seguros en n8n 2.0