6. Mapear los modos de falla de un flujo

Descripción

Al terminar esta lección vas a poder tomar cualquier workflow y listar, de forma sistemática, las maneras en que puede salir mal —no las infinitas maneras teóricas, sino los cuatro modos concretos que de verdad importan en automatización—. Vas a conocer esos cuatro modos por su nombre —fallo parcial, doble disparo, orden alterado y cambio de esquema aguas arriba— y vas a tener un método para recorrer un flujo nodo por nodo preguntándote, en cada punto, qué pasa si ese modo golpea justo ahí.

Esto importa porque "¿qué puede salir mal?" es una pregunta paralizante si la haces en abstracto —las cosas pueden salir mal de mil formas— y se vuelve manejable en cuanto tienes una lista corta y cerrada. Los cuatro modos de esta lección son esa lista. Un dueño del sistema no improvisa cada vez que evalúa un riesgo; recorre los cuatro, uno por uno, sobre el flujo concreto, y sabe que si los cubrió, cubrió lo que importa. Es la diferencia entre una preocupación vaga y una checklist.

Conexión con el módulo: las lecciones 4 y 5 te dieron dos de los cuatro modos en profundidad —el doble disparo (su origen en la entrega "al menos una vez", su mecánica en el modelo de ejecución) y su primo, el reintento—. Esta lección los coloca en un cuadro más grande, junto a los otros dos que aún no nombramos con precisión: el fallo parcial (que asomó en la línea de tiempo de la lección 2) y el cambio de esquema (que asomó en la pregunta 3 del dueño). La lección 7 te dará la herramienta para saber cuáles nodos son peligrosos cuando un modo golpea —la distinción lectura/efecto— y la lección 8 junta todo en una auditoría real. Esta lección es el inventario; la 7 es el criterio; la 8 es la práctica.

Por qué cuatro, y no mil

Antes de los modos, una palabra sobre por qué son manejables.

Si te sientas a pensar "¿de cuántas formas puede fallar order-triage?", la lista parece infinita: el CRM puede caerse, la pasarela puede rechazar la tarjeta, el agente puede clasificar mal, la red puede parpadear, el disco puede llenarse, alguien puede desconectar un cable. Ante esa infinidad, la reacción natural es rendirse o cubrir al azar.

Pero fíjate en algo: casi todas esas fallas, desde el punto de vista del estado del sistema —las huellas durables que quedan, como definimos en la lección 3— se reducen a unos pocos patrones. No importa si el correo no salió porque el servicio estaba caído, porque la red parpadeó o porque el disco se llenó; desde el punto de vista del estado, el resultado es el mismo: un efecto que debía ocurrir no ocurrió, y el flujo se cortó a la mitad. Ese patrón es lo que llamamos un modo de falla, y hay solo cuatro que importan para la confiabilidad.

Un modo de falla es una forma característica en que un flujo puede dejar el estado incorrecto, definida por el patrón del daño y no por la causa técnica específica. Agrupar las mil causas en cuatro patrones es lo que vuelve el problema abordable. En lugar de defenderte de cada causa —una tarea sin fin— te defiendes de cada patrón, y cada patrón tiene una familia de soluciones que la guía te enseña.

Fíjate en el beneficio de razonar por patrones en vez de por causas: las causas son innumerables y cambian con la tecnología —el año que viene habrá formas de fallar que hoy no existen— pero los patrones son estables. "El flujo se cortó a la mitad" describe igual de bien un servidor caído en 2010 que uno caído hoy. Aprender los cuatro modos no es aprender una lista de problemas de moda; es aprender las cuatro formas fundamentales en que un proceso con efectos puede terminar en un estado incorrecto. Esa estabilidad es lo que hace que valga la pena memorizarlos: te van a servir con cualquier herramienta, no solo con n8n.

Veamos los cuatro.

Modo 1: Fallo parcial

Qué es. El flujo hace algunos de sus efectos y luego se corta, dejando el resto sin hacer. El sistema queda a medias: unos papeles firmados, otros no.

La anatomía. Un workflow con varios efectos en secuencia —crear, cobrar, enviar— es una fila de acciones. El fallo parcial ocurre cuando la fila se interrumpe en medio: las acciones anteriores al corte ya dejaron su huella durable, las posteriores no. El punto exacto donde se corta determina en qué estado queda el sistema.

La analogía. Es el trámite a medias. Vas a hacer una gestión que tiene cinco ventanillas: pagas en la primera, sellan en la segunda, y en la tercera te dicen "el sistema se cayó, vuelve mañana". Ya pagaste —ese efecto quedó— pero el trámite no está completo. No es que no pasó nada; es que pasó una parte, y esa parte a medias es más difícil de manejar que si no hubiera pasado nada. Si mañana empiezas el trámite de cero, ¿te cobran otra vez?

En order-triage. Ya lo viste en la línea de tiempo de la lección 2. Si Create charge cobra y luego Send Email falla, el estado es: pedido registrado, cliente cobrado, sin correo de confirmación. El cliente pagó y no tiene comprobante. Y el peligro no termina ahí: el intento de recuperarse —reintentar el flujo completo— vuelve a cobrar. El fallo parcial es peligroso por sí mismo (estado a medias) y por lo que provoca (un reintento que duplica).

Por qué es el más traicionero. Un fallo total —donde no se hizo nada— es fácil: el estado quedó limpio, reintentas y listo. Un fallo parcial deja el sistema en un punto intermedio del que no hay una salida obvia, porque reintentar desde el principio repite lo ya hecho, y continuar desde donde se cortó requiere saber exactamente qué se hizo. Esa necesidad de "saber qué se hizo" es, otra vez, la memoria del estado del Módulo 4.

Hay una asimetría que conviene fijar: cuanto más tarde en el flujo ocurre el corte, más grave es el fallo parcial. Un corte al principio —antes del primer efecto— deja el estado limpio, como si nada hubiera pasado. Un corte al final —después de todos los efectos menos uno— deja casi todo hecho y solo una cosa pendiente, y esa "cosa pendiente" es la que tienta a reintentar el flujo completo, repitiendo todo lo demás. Por eso, al mapear el fallo parcial, no basta con preguntar "¿puede cortarse?"; hay que preguntar "¿dónde puede cortarse, y qué queda hecho en cada punto?". El punto de corte más peligroso es siempre el que está justo después del efecto menos reversible, porque combina lo peor de los dos mundos: el daño grave ya ocurrió y la recuperación amenaza con duplicarlo.

Modo 2: Doble disparo

Qué es. El mismo evento entra dos veces —o más— y el flujo se ejecuta completo cada vez, duplicando todos sus efectos.

La anatomía. Como viste en las lecciones 4 y 5: la entrega "al menos una vez" hace que el disparador entregue el mismo evento más de una vez; n8n crea una ejecución por entrega; cada ejecución corre todos los efectos. El daño no es a medias como el fallo parcial —aquí todo se hace— sino doble.

La analogía. Es el repartidor de la lección 5 dejando dos documentos idénticos. Salvo que ahora el documento no solo llega dos veces: cada copia dispara toda una cadena de consecuencias. Es como si cada vez que llega el documento, tú, obediente, ejecutaras la orden que contiene —"cóbrale al cliente"— sin recordar que ya la ejecutaste con la copia anterior.

En order-triage. El pedido evt_8f2a91c4 entra a las 09:12:03 y otra vez a las 09:12:05. Dos ejecuciones, dos registros, dos cobros, dos correos. Es el drama central de la guía, y es el modo mejor entendido a esta altura porque le dedicamos dos lecciones.

Su relación con el reintento. El doble disparo externo (el proveedor reenvía) y el reintento interno (n8n vuelve a correr) son primos: los dos hacen que el flujo se ejecute más de una vez sobre el mismo evento. La defensa es la misma para ambos —idempotencia— y por eso conviene pensarlos juntos.

Modo 3: Orden alterado

Qué es. Los eventos llegan o se procesan en un orden distinto al que ocurrieron de verdad, y el flujo, que asumía un orden, hace algo incorrecto.

La anatomía. Cuando varios eventos relacionados viajan por canales que no garantizan el orden —o cuando varias ejecuciones corren en paralelo, como viste en la lección 4— el orden en que tu workflow los procesa puede no coincidir con el orden real. Un evento "posterior" puede procesarse antes que uno "anterior".

La analogía. Son dos cartas que se cruzan en el correo. Le escribes a alguien "te mando el paquete el lunes" y al día siguiente "cancela, no lo mando". Si las cartas llegan en orden, todo bien. Pero si la segunda llega antes que la primera, el destinatario lee "cancela" y después "te lo mando", y termina esperando un paquete que cancelaste. El contenido de cada carta es correcto; el orden en que llegaron produjo una conclusión falsa.

En order-triage. Imagina que a un pedido le llega primero un evento "pedido creado" y poco después un evento "pedido cancelado". Si por un solapamiento de ejecuciones el flujo procesa la cancelación antes que la creación, podría intentar cancelar un pedido que todavía no registró, o —peor— registrar el pedido después de haber procesado su cancelación, dejándolo activo cuando debía estar cancelado. El estado final depende de un orden que no controlas.

Por qué es más sutil. El orden alterado no siempre hace daño: muchos flujos procesan eventos independientes donde el orden no importa (tres pedidos distintos pueden procesarse en cualquier orden sin problema). Solo importa cuando hay eventos relacionados cuyo efecto depende de la secuencia. Reconocer cuándo tu flujo tiene esa dependencia de orden es la habilidad; la guía lo trata a fondo en el Módulo 5, con la coordinación entre workflows.

Modo 4: Cambio de esquema aguas arriba

Qué es. Los datos que entran al flujo cambian de forma —un campo se renombra, cambia de tipo, aparece o desaparece— porque quien los produce los cambió, y el flujo, que esperaba la forma vieja, hace algo incorrecto o falla.

La anatomía. Tu workflow recibe datos de alguien más: un proveedor, un formulario, otra parte del sistema. Ese "alguien" puede cambiar el formato sin avisarte, porque no hay un contrato explícito que se lo impida. Un amount que venía como número ahora viene como texto; un campo customer_name que siempre estaba ahora a veces falta.

La analogía. Es el formulario que cambió de versión sin avisar. Llenas el trámite como siempre, pero resulta que la casilla que antes era "monto en pesos" ahora es "monto en dólares", y nadie te lo dijo. Escribes 2154 pensando en pesos, el sistema lo lee como dólares, y el cobro sale por una cifra absurda. Cada uno hizo su parte; el desajuste entre la forma que esperabas y la que llegó produjo el error.

En order-triage. La tienda en línea actualiza su sistema y empieza a mandar amount como texto —"2154.00" en vez de 2154.00—. El nodo Create charge podría cobrar un monto mal interpretado, o fallar de una forma que dispare un reintento, que a su vez duplica. Un cambio silencioso arriba se convierte en un cobro incorrecto o duplicado abajo. Otra variante: aparece un pedido sin el campo customer_id, y el flujo crea un registro huérfano o se rompe a la mitad, produciendo un fallo parcial.

La defensa, en una palabra: contratos. La forma de protegerse del cambio de esquema es tener un acuerdo explícito sobre qué forma tienen los datos, y validarla en la frontera —antes de tocar nada— para que un dato inesperado falle limpio y temprano, no sucio y tarde. Ese acuerdo es un contrato, y es el Módulo 3 completo. Por ahora, el modo a reconocer es: los datos de entrada pueden cambiar, y un flujo que confía ciegamente en su forma es frágil.

Vale la pena notar por qué este modo es distinto de los otros tres. El fallo parcial, el doble disparo y el orden alterado nacen de la infraestructura —redes, reintentos, ejecuciones paralelas— que en gran medida no controlas. El cambio de esquema nace de una persona o un equipo que decidió cambiar algo del otro lado de la frontera. Eso lo hace, en un sentido, más manejable: puedes acordar un contrato, pedir aviso antes de un cambio, versionar el formato. Pero también más silencioso: un cambio de esquema no genera un error de red que alguien note; genera datos que llegan "distintos" y que tu flujo procesa sin quejarse hasta que el daño ya está hecho. Por eso la defensa no es esperar el fallo, sino validar activamente en la entrada: convertir un cambio silencioso en un rechazo ruidoso y temprano.

Cómo se combinan los modos: la cascada

Los cuatro modos son limpios cuando los estudias por separado, pero en la vida real rara vez llegan solos. Lo más peligroso —y lo más común— es que uno provoque otro, en cascada. Vale la pena verlo, porque explica por qué un problema que empieza chico termina en un cobro duplicado.

Sigue esta secuencia, que encadena tres de los cuatro modos:

Cambio de esquema  →  Fallo parcial  →  (reintento de recuperación)  →  Doble disparo

Paso a paso, en order-triage:

1. Cambio de esquema. La tienda empieza a mandar amount como texto. El nodo Create charge recibe "2154.00" donde esperaba un número.
2. Fallo parcial. Create CRM order ya había creado el registro (no le afectaba el cambio), pero Create charge falla al procesar el texto raro. La ejecución se corta: registro creado, sin cobro. Estado a medias.
3. Reintento de recuperación. Alguien ve la ejecución en rojo y la reintenta completa para "arreglarla".
4. Doble disparo (por reintento). El reintento vuelve a pasar por Create CRM order —que esta vez sí funciona— y crea un segundo registro. Un problema que empezó como un simple cambio de formato terminó en un registro duplicado, y si el cambio de esquema se hubiera resuelto entre medio, incluso en un cobro.

Mira lo que pasó: ningún paso fue absurdo por sí solo. El cambio de formato es normal, el fallo es honesto, el reintento es bienintencionado. Pero encadenados producen un daño que ninguno causaba por separado. Por eso el dueño del sistema no evalúa los modos como una lista de casillas independientes, sino que se pregunta también "¿este modo puede disparar otro?". Las cascadas más comunes son dos:

• Cambio de esquema → fallo parcial: un dato inesperado rompe un nodo a la mitad del flujo, dejando el estado a medias. (Se corta con validación en la frontera: Módulo 3.)
• Fallo parcial → doble disparo: el reintento para recuperarse de un estado a medias repite los efectos ya hechos. (Se corta con idempotencia: Módulo 2 y 6.)

La buena noticia es que las defensas también encadenan: si validas en la frontera, evitas que el cambio de esquema entre; si tus efectos son idempotentes, el reintento deja de duplicar. Una cascada de fallos se detiene con una cascada de defensas, y por eso vale la pena mapear no solo los modos sueltos sino sus encadenamientos.

El método: recorrer el flujo con los cuatro modos

Tener los cuatro modos no basta; hay que aplicarlos con método. El método es simple y mecánico, que es justo lo que quieres cuando el objetivo es no olvidar nada:

Paso 1 — Dibuja el flujo como una secuencia de nodos. Ponlos en orden, de izquierda a derecha, como venimos haciendo con order-triage.

Paso 2 — Para cada modo, recorre el flujo preguntando "¿qué pasa si este modo golpea aquí?". No un vistazo general; nodo por nodo. Para el fallo parcial: ¿qué queda si se corta justo después de este nodo? Para el doble disparo: ¿qué hace este nodo si se ejecuta dos veces? Para el orden alterado: ¿este nodo asume que algo pasó antes? Para el cambio de esquema: ¿qué campos lee este nodo y qué pasa si vienen distintos?

Paso 3 — Anota, para cada punto peligroso, el modo, el nodo y la consecuencia. No la solución todavía —eso es el resto de la guía— sino el riesgo, concreto: "doble disparo en Create charge → segundo cobro".

Paso 4 — Ordena por gravedad. Usa la reversibilidad de la lección 3: los efectos menos reversibles y más costosos primero. Un cobro duplicado sube; un registro duplicado en el CRM baja.

El resultado es un mapa de riesgo del flujo: una lista corta y priorizada de qué puede salir mal y qué tan grave sería. Ese mapa es el entregable de la lección 8, y es, en la práctica, lo que un dueño del sistema produce antes de poner cualquier flujo importante en producción.

Ejemplo trabajado: los cuatro modos sobre order-triage

Vamos a aplicar el método completo. Este es el flujo:

Webhook  →  Get customer  →  AI Agent  →  Create CRM order  →  Create charge  →  Send Email

Recorramos los cuatro modos.

Fallo parcial. ¿Dónde puede cortarse y qué queda?

Se corta después de…	Estado que queda	Gravedad
Get customer	Nada durable hecho. Limpio.	Baja: reintentar es seguro
AI Agent	Nada durable hecho (la clasificación es pasajera).	Baja
Create CRM order	1 registro, sin cobro ni correo	Media: pedido registrado pero no cobrado
Create charge	1 registro, 1 cobro, sin correo	Alta: cliente pagó sin confirmación, y reintentar duplica el cobro

El punto negro es el corte después de Create charge: cliente cobrado sin comprobante, y un reintento ingenuo cobra de nuevo.

Doble disparo. ¿Qué hace cada efecto si el flujo corre dos veces?

• Create CRM order dos veces → 2 registros. Reversible, molesto.
• Create charge dos veces → 2 cobros. Poco reversible, costoso. El riesgo número uno.
• Send Email dos veces → 2 correos. Reversible en impacto, leve.

Orden alterado. ¿order-triage depende del orden entre eventos? Tal como está —procesa cada pedido de forma independiente— el orden entre pedidos distintos no importa. Pero si Cumbre empezara a mandar eventos de "pedido cancelado" que se relacionan con un "pedido creado" previo, ahí aparecería la dependencia de orden. Hoy: riesgo bajo. Con eventos relacionados: a vigilar.

Cambio de esquema. ¿Qué campos lee cada nodo y qué pasa si cambian?

• Create charge lee amount y currency. Si amount llega como texto o cambia de moneda sin aviso → cobro incorrecto. Alta.
• Create CRM order lee customer_id, order_id. Si falta customer_id → registro huérfano o fallo parcial. Media.
• Get customer lee customer_id. Si falta → la lectura falla temprano, lo cual —irónicamente— es el fallo más limpio, porque corta antes de cualquier efecto.

El mapa de riesgo resultante, ordenado por gravedad:

#	Modo	Nodo	Consecuencia	Gravedad
1	Doble disparo	Create charge	Segundo cobro	Crítica
2	Fallo parcial	corte tras Create charge	Cobrado sin correo; el reintento duplica	Alta
3	Cambio de esquema	Create charge	Cobro con monto/moneda incorrectos	Alta
4	Doble disparo	Create CRM order	Registro duplicado	Media
5	Cambio de esquema	Create CRM order	Registro huérfano	Media
6	Doble disparo	Send Email	Correo duplicado	Baja

Qué esperar de este ejercicio. Fíjate en el resultado: partiendo de un flujo que "funciona", produjiste seis riesgos concretos, cada uno con su nodo, su consecuencia y su gravedad. Y observa el patrón: los riesgos se concentran en Create charge —aparece tres veces, siempre alto— porque es el efecto menos reversible del flujo. Eso te dice, antes de escribir una sola línea de solución, dónde poner tu primer esfuerzo. Ese enfoque —dejar que el mapa te muestre dónde duele más— es exactamente lo que hace un dueño del sistema, y es lo que vas a practicar por tu cuenta en la lección 8.

Errores comunes

Buscar "todas" las formas de fallar en vez de los cuatro modos (conceptual). Qué pasa: alguien intenta anticipar cada causa técnica posible —cada servicio que puede caer, cada error de red— y se pierde en una lista infinita, o se rinde. Por qué pasa: "¿qué puede salir mal?" es infinito si lo piensas por causas. Cómo detectarlo: si tu análisis de riesgo tiene veinte entradas sobre fallos de infraestructura y ninguna sobre duplicados, estás enumerando causas, no modos. Cómo corregirlo: agrupa por patrón de daño, no por causa. Las mil causas colapsan en cuatro modos —fallo parcial, doble disparo, orden alterado, cambio de esquema— y cada modo tiene su familia de defensas. Cubrir los cuatro cubre lo que importa.

Olvidar el fallo parcial porque "el workflow no dio error" (conceptual). Qué pasa: se revisa el doble disparo pero no el fallo parcial, porque el fallo parcial no siempre se ve como un error rojo —a veces la ejecución falla, pero el daño (el cobro sin correo) queda escondido en un estado a medias—. Por qué pasa: el doble disparo es más famoso y más intuitivo; el fallo parcial es silencioso. Cómo detectarlo: si tu análisis solo pregunta "¿qué pasa si corre dos veces?" y nunca "¿qué queda si se corta a la mitad?", te falta un modo. Cómo corregirlo: para cada workflow con más de un efecto en secuencia, recorre los puntos de corte uno por uno. El fallo parcial vive entre efecto y efecto, y es donde nacen los reintentos que duplican.

Suponer que el orden nunca importa (conceptual). Qué pasa: se descarta el modo de orden alterado porque "mis eventos son independientes", y luego aparecen eventos relacionados —una creación y su cancelación— cuyo orden sí decide el resultado. Por qué pasa: en muchos flujos el orden de verdad no importa, así que es fácil generalizar de más. Cómo detectarlo: pregúntate si algún par de eventos de tu flujo tiene una relación de "esto depende de que aquello haya pasado antes". Si la tiene, el orden importa. Cómo corregirlo: no descartes el modo por defecto; verifica si hay dependencia de orden. Cuando la haya, es real y es del Módulo 5.

Confundir el mapa de riesgo con la solución (conceptual). Qué pasa: alguien hace un análisis de modos de falla excelente y cree que con eso el workflow ya es confiable. Pero mapear el riesgo es diagnosticar, no curar. Por qué pasa: el alivio de ver el problema se confunde con haberlo resuelto. Cómo detectarlo: si tienes un mapa de riesgo pero ningún efecto protegido, diagnosticaste sin tratar. Cómo corregirlo: el mapa es el primer paso —indispensable, porque no puedes proteger lo que no ves— pero el tratamiento son los módulos siguientes. Este módulo entero, incluida esta lección, es diagnóstico; la cura empieza en el Módulo 2.

Ejercicios

Ejercicio 1 — Identifica el modo. Para cada situación, di cuál de los cuatro modos de falla describe.

(a) El cliente pagó pero nunca recibió el correo de confirmación porque el servicio de correo estaba caído. (b) La tienda cambió su sistema y ahora manda las fechas en otro formato; el nodo que las procesa empieza a fallar. (c) Un pedido se procesó dos veces porque el proveedor lo reenvió. (d) Una cancelación se procesó antes que la creación del mismo pedido, dejándolo activo cuando debía estar cancelado.

Ver solución

(a) Fallo parcial. El flujo hizo unos efectos (cobro) y se cortó antes de otros (correo), dejando el estado a medias.

(b) Cambio de esquema aguas arriba. Los datos de entrada cambiaron de forma y el flujo, que esperaba la forma vieja, falla.

(c) Doble disparo. El mismo evento entró dos veces y el flujo duplicó sus efectos.

(d) Orden alterado. Dos eventos relacionados se procesaron en un orden distinto al real, produciendo un estado incorrecto.

Por qué funciona: los cuatro modos son excluyentes en su patrón —a medias, doble, desordenado, deforme— aunque en la vida real pueden combinarse (un cambio de esquema puede causar un fallo parcial). Nombrar el modo correctamente es el primer paso para saber qué familia de defensas aplica.

Ejercicio 2 — Mapea un flujo nuevo. Cumbre tiene otro workflow, refund-handler, que procesa reembolsos:

Webhook  →  Get order  →  Create refund  →  Update CRM status  →  Send Email
(recibe      (lee el       (reembolsa en     (marca el pedido     (avisa al
 el evento)   pedido)       la pasarela)      como reembolsado)    cliente)

Aplica el método: recorre los cuatro modos y arma un mapa de riesgo con al menos cuatro entradas, ordenadas por gravedad. Usa la reversibilidad para ordenar.

Ver solución

Un mapa razonable:

#	Modo	Nodo	Consecuencia	Gravedad
1	Doble disparo	Create refund	Segundo reembolso: se devuelve dinero dos veces	Crítica
2	Fallo parcial	corte tras Create refund	Reembolsado pero el CRM sigue diciendo "pendiente"; un reintento reembolsa de nuevo	Alta
3	Cambio de esquema	Create refund	Reembolso por monto incorrecto si el campo del monto cambia	Alta
4	Doble disparo	Update CRM status	Estado marcado dos veces (reversible, cosmético)	Baja
5	Doble disparo	Send Email	Correo de aviso duplicado	Baja

El punto crítico es Create refund: un reembolso duplicado devuelve dinero de más, y es tan poco reversible y costoso como un cobro duplicado, solo que en la dirección opuesta. Fíjate que el patrón se repite respecto de order-triage: el efecto que mueve dinero es siempre el de mayor gravedad, y el fallo parcial justo después de él es el segundo riesgo, porque el reintento de recuperación duplica.

Por qué funciona: acabas de auditar un flujo que nunca habías visto usando solo el método —cuatro modos, recorrido nodo por nodo, orden por reversibilidad— y llegaste al mismo tipo de conclusión que en order-triage. Eso es lo que hace valioso el método: no depende de conocer el flujo de antemano, se aplica a cualquiera.

Ejercicio 3 — Encuentra la dependencia de orden. De estos tres pares de eventos, ¿en cuáles importa el orden en que se procesan y en cuáles no? Justifica.

(a) Dos pedidos distintos de dos clientes distintos. (b) "Pedido creado" y "pedido pagado" del mismo pedido. (c) Dos consultas de "dame el estado del cliente CUST-118".

Ver solución

(a) El orden no importa. Son eventos independientes: procesar el pedido de un cliente antes o después del de otro da el mismo resultado. No hay relación entre ellos.

(b) El orden sí importa. Son eventos relacionados con una dependencia: "pagado" asume que "creado" ya ocurrió. Si se procesa "pagado" antes de "creado", el flujo podría intentar marcar como pagado un pedido que aún no existe en su sistema. Aquí el modo de orden alterado es real.

(c) El orden no importa. Son dos lecturas idénticas. Consultar el estado dos veces, en cualquier orden, da el mismo resultado y no cambia nada. Las lecturas, como verás en la lección 7, son inmunes a casi todos los modos de falla, incluido el orden.

Por qué funciona: la dependencia de orden existe solo cuando un evento asume un estado que otro evento produce. Eventos independientes (a) y lecturas repetidas (c) no tienen esa dependencia. Reconocer el caso (b) —donde un evento presupone que otro ya pasó— es exactamente la señal de que el modo de orden alterado aplica, y es lo que el Módulo 5 te enseña a manejar.

Resumen y siguiente paso

En esta lección convertiste la pregunta paralizante "¿qué puede salir mal?" en una checklist de cuatro modos de falla, definidos por el patrón del daño y no por la causa técnica. El fallo parcial: el flujo hace unos efectos y se corta, dejando el estado a medias —el más traicionero, porque el reintento de recuperación duplica—. El doble disparo: el mismo evento entra dos veces y todos los efectos se duplican —el drama central de la guía—. El orden alterado: eventos relacionados se procesan en una secuencia distinta a la real, produciendo un estado incorrecto —sutil, porque solo importa cuando hay dependencia de orden—. Y el cambio de esquema aguas arriba: los datos de entrada cambian de forma y el flujo que esperaba la forma vieja falla o hace algo incorrecto —cuya defensa son los contratos del Módulo 3—.

Y te llevas el método para aplicarlos: dibuja el flujo, recorre cada modo nodo por nodo preguntando "¿qué pasa si golpea aquí?", anota modo–nodo–consecuencia, y ordena por reversibilidad. Lo aplicaste a order-triage y produjiste un mapa de seis riesgos que se concentraban en Create charge, el efecto menos reversible —mostrándote, antes de cualquier solución, dónde poner el primer esfuerzo—.

Antes de avanzar deberías poder: nombrar los cuatro modos de falla y dar un ejemplo de cada uno; explicar por qué el fallo parcial es más traicionero que el fallo total; y aplicar el método a un flujo para producir un mapa de riesgo priorizado.

Notaste algo en los mapas de riesgo: no todos los nodos aparecen. Get customer casi nunca es un riesgo; Create charge aparece una y otra vez. Eso no es casualidad, y la lección 7 lo vuelve un principio. Es la distinción que sostiene toda la guía —entre una lectura, que se puede repetir sin daño, y un efecto, que no— y es la que te dice, de un vistazo, cuáles nodos necesitan protección y cuáles puedes ignorar. Es la bisagra conceptual del módulo, y con ella la auditoría de la lección 8 deja de ser laboriosa y se vuelve casi automática.

Recursos

• Error handling — n8n Docs — el arsenal de n8n contra los modos de falla; leerlo con los cuatro modos en la cabeza te ayuda a ver qué herramienta ataca cuál patrón.
• Error Trigger node — n8n Docs — el nodo que se dispara cuando un workflow falla; la base para detectar fallos parciales y enrutarlos, que el Módulo 6 desarrolla.
• Stop And Error node — n8n Docs — el nodo para fallar a propósito y temprano; una pieza clave para convertir un cambio de esquema en un fallo limpio en la frontera en vez de un daño tardío.
• Executions — n8n Docs — donde observas, después del hecho, en qué punto se cortó una ejecución; la evidencia con la que confirmas un fallo parcial real.