8. Práctica: auditar un workflow frágil

Descripción

Al terminar esta lección vas a haber hecho, de principio a fin, una auditoría de confiabilidad completa sobre un workflow que no habías visto —el mismo trabajo que un dueño del sistema hace antes de poner cualquier flujo importante en producción—. Vas a tener un método de cuatro pasos que integra todo lo del módulo, un entregable concreto —la tabla de riesgo por nodo— y la seguridad de que puedes aplicar el método a cualquier workflow, tuyo o ajeno, sin necesidad de que alguien te diga dónde están los peligros.

Esto importa porque es la capacidad de salida del módulo entero. Todo lo anterior —constructor vs dueño, confiable, el modelo de ejecución, "al menos una vez", los cuatro modos de falla, lecturas vs efectos— eran piezas. Esta lección las ensambla en una habilidad práctica que puedes ejecutar y mostrar. Una auditoría es, además, lo que te piden demostrar en una entrevista técnica y lo que le entregas a un equipo cuando te preguntan "¿es seguro poner esto en producción?".

Conexión con el módulo: esta es la lección de cierre y de síntesis. No introduce conceptos nuevos; convierte los que ya tienes en un procedimiento repetible. El paso de clasificación viene de la lección 7 (lecturas vs efectos), el de modos de falla viene de la lección 6, la priorización por reversibilidad viene de la lección 3, y la predicción del doble disparo viene de las lecciones 4 y 5. Al terminar, cierras el Módulo 1 con una capacidad concreta —auditar— y quedas listo para el Módulo 2, que toma los riesgos que tu auditoría encontró y te enseña a repararlos con idempotencia.

Qué es una auditoría de confiabilidad

Antes de hacerla, definámosla, porque la palabra "auditoría" puede sonar más solemne de lo que es.

Una auditoría de confiabilidad es, simplemente, examinar un workflow para encontrar dónde puede hacer daño al fallar o al repetirse, y anotarlo de forma ordenada. No es arreglar nada —eso viene después—; es diagnosticar. Como la revisión que un mecánico le hace a un auto antes de un viaje largo: no cambia las piezas todavía, primero recorre el auto punto por punto y anota "esta llanta está gastada, este freno chirría, este foco no prende", ordenado por qué tan grave es. Con esa lista, tú decides qué reparar y en qué orden.

La auditoría produce un documento —la tabla de riesgo por nodo— que responde tres preguntas sobre el workflow:

1. ¿Qué hace cada nodo? ¿Es una lectura o un efecto? (Lección 7.)
2. ¿Cómo puede fallar? ¿Qué modos de falla lo golpean y con qué consecuencia? (Lección 6.)
3. ¿Qué tan grave es? Ordenado por reversibilidad y costo. (Lección 3.)

Fíjate en que la auditoría es puro diagnóstico. No dice cómo arreglar; dice qué está en riesgo. Esa separación es sana: primero ves el problema completo, con la cabeza fría, y solo después eliges las soluciones. Mezclar diagnóstico y solución —"veo un riesgo, lo arreglo, sigo"— es cómo se pierden los riesgos que no saltan a la vista.

El método de auditoría en cuatro pasos

Este es el procedimiento. Es deliberadamente mecánico, porque el objetivo es no olvidar nada, y una checklist no olvida.

Paso 1 — Dibuja el flujo y clasifica cada nodo. Pon los nodos en orden. Para cada uno, aplica la prueba de la repetición de la lección 7: "¿ejecutarlo dos veces cambia el mundo?". Márcalo como lectura (no) o efecto (sí). Este paso solo ya te dice dónde vas a concentrar todo lo demás, porque los modos de falla muerden sobre todo en los efectos.

Paso 2 — Para cada efecto, recorre los cuatro modos de falla. Toma cada nodo que marcaste como efecto y pregúntale los cuatro modos de la lección 6: ¿qué pasa si el flujo se corta justo después (fallo parcial)?, ¿qué pasa si se ejecuta dos veces (doble disparo)?, ¿depende de un orden (orden alterado)?, ¿qué pasa si sus datos de entrada cambian (cambio de esquema)? Anota cada riesgo real que encuentres.

Paso 3 — Predice el doble disparo de punta a punta. Aparte del recorrido nodo por nodo, imagina el flujo completo ejecutándose dos veces sobre el mismo evento —el escenario central de la guía— y escribe, en una frase, el estado final: "dos registros, dos cobros, dos correos". Esta predicción global es lo que más le importa a quien lee tu auditoría.

Paso 4 — Arma la tabla y ordena por gravedad. Junta todos los riesgos en una tabla con columnas: nodo, tipo (lectura/efecto), modo de falla, consecuencia, gravedad. Ordena por gravedad usando la reversibilidad de la lección 3: los efectos menos reversibles y más costosos arriba. Esa tabla ordenada es tu entregable.

El resultado de los cuatro pasos es un mapa que cualquiera —tú, tu equipo, un entrevistador— puede leer para entender, en treinta segundos, dónde está el peligro de un workflow y por dónde empezar a repararlo.

Ejemplo trabajado: auditamos subscription-billing juntos

Vamos a auditar un workflow nuevo, paso a paso, para que veas el método en acción antes de aplicarlo tú. Es de Cumbre, pero no lo habías visto: se llama subscription-billing y cobra las suscripciones mensuales de los clientes que tienen un plan de entrega recurrente de café.

Este es el flujo. Se dispara cada vez que llega un evento de "toca cobrar la suscripción de este cliente":

Webhook            →  Get subscription   →  Create charge      →  Insert billing row  →  Update next_date   →  Send Email
(recibe el evento     (lee el plan y       (cobra la mensualidad  (guarda la fila de     (adelanta la fecha    (manda el recibo
 de cobro mensual)     el monto del CRM)    en la pasarela)        cobro en nuestra BD)   del próximo cobro)    al cliente)

Y este es un evento de ejemplo que llega al webhook:

{
  "event_id": "evt_bill_5521",
  "subscription_id": "SUB-3092",
  "customer_id": "CUST-118",
  "billing_period": "2026-08",
  "created_at": "2026-08-01T06:00:00.000Z"
}

Paso 1: clasificar cada nodo

Aplico la prueba de la repetición a cada uno.

Nodo	¿Repetirlo cambia el mundo?	Tipo
Webhook	Es la entrada	Disparador
Get subscription	No: leer el plan lo deja igual	Lectura
Create charge	Sí: cobra otra vez	Efecto
Insert billing row	Sí: inserta otra fila	Efecto
Update next_date	Depende de cómo esté escrito (ver abajo)	Efecto (con matiz)
Send Email	Sí: manda otro recibo	Efecto

Ya con esto sé dónde mirar: cuatro efectos (Create charge, Insert billing row, Update next_date, Send Email) y una sola lectura (Get subscription) que puedo soltar.

Una nota sobre Update next_date, porque es un caso de la lección 7. Si el nodo fija la fecha —"pon next_date en 2026-09-01"— es idempotente: repetir lo deja igual. Pero si la avanza en relativo —"súmale un mes a next_date"— NO es idempotente: dos ejecuciones adelantan dos meses, y el cliente se saltaría un cobro. Anoto esto como un riesgo a verificar, porque el mismo nombre de nodo esconde dos comportamientos con seguridad de repetición opuesta.

Paso 2: recorrer los cuatro modos sobre cada efecto

Create charge (el más grave, porque mueve dinero y es poco reversible):

• Doble disparo → segundo cobro de la mensualidad. Crítico.
• Fallo parcial (corte justo después) → cobrado, pero sin fila de registro ni fecha actualizada; un reintento vuelve a cobrar. Alto.
• Cambio de esquema → si el monto de la suscripción cambia de formato, cobra mal. Alto.
• Orden alterado → si llegan dos periodos de cobro y se procesan al revés, podría cobrarse el mes equivocado. Medio.

Insert billing row (escribe en nuestra propia base de datos):

• Doble disparo → dos filas para el mismo periodo. Ensucia los reportes, pero es reversible. Medio.
• Fallo parcial → si se corta después de esta fila pero antes del correo, hay registro sin recibo. Bajo-medio.

Update next_date:

• Doble disparo → si es relativo, adelanta dos meses (el cliente se salta un cobro: pierde dinero Cumbre). Si es fijo, sin daño. Depende de la implementación: alto o nulo.

Send Email:

• Doble disparo → dos recibos idénticos. Molesto, reversible. Bajo.

Paso 3: predecir el doble disparo de punta a punta

Si el evento evt_bill_5521 llega dos veces —el proveedor reintenta, o n8n reintenta— y no hay protección, el flujo corre completo dos veces. Estado final:

Dos cobros de la mensualidad, dos filas de facturación para el periodo 2026-08, la fecha del próximo cobro posiblemente adelantada de más, y dos recibos. El cliente paga doble su suscripción del mes.

Esa frase es lo primero que leería quien recibe la auditoría.

Paso 4: la tabla de riesgo, ordenada por gravedad

#	Nodo	Tipo	Modo de falla	Consecuencia	Gravedad
1	Create charge	Efecto	Doble disparo	Segundo cobro de la mensualidad	Crítica
2	Create charge	Efecto	Fallo parcial + reintento	Cobrado sin registro; el reintento duplica el cobro	Alta
3	Update next_date	Efecto	Doble disparo (si es relativo)	Fecha adelantada de más; el cliente se salta un cobro	Alta (a verificar)
4	Create charge	Efecto	Cambio de esquema	Cobro por monto incorrecto	Alta
5	Insert billing row	Efecto	Doble disparo	Dos filas para el mismo periodo	Media
6	Send Email	Efecto	Doble disparo	Recibo duplicado	Baja
—	Get subscription	Lectura	—	Segura de repetir; sin riesgo	Ninguna

Qué esperar de esta auditoría. Partiendo de un workflow que nunca habías visto y que "funciona", produjiste siete filas de diagnóstico, priorizadas, con la lectura correctamente identificada como sin riesgo. El punto crítico —Create charge— salta a la vista, y aparece un riesgo que un vistazo casual no habría encontrado: el de Update next_date, que depende de un detalle de implementación (fijar vs sumar) invisible en el diagrama. Esa es exactamente la clase de riesgo escondido que el método, aplicado con disciplina, saca a la luz.

Y fíjate en la pista de solución que ya tienes, aunque no la construyamos hasta el Módulo 2: el evento trae un event_id (evt_bill_5521). Esa es la clave con la que, más adelante, subscription-billing va a reconocer el reintento y detenerse antes de cobrar de nuevo.

Una plantilla reutilizable para tus auditorías

Para que el método no se te escape, aquí tienes una plantilla que puedes copiar y llenar para cualquier workflow. No es un formato oficial de n8n; es un andamio que ordena los cuatro pasos. Con el tiempo lo vas a hacer de memoria, pero al principio conviene tenerlo delante.

AUDITORÍA DE CONFIABILIDAD — <nombre del workflow>
Disparador: <qué lo dispara> · Evento de ejemplo: <event_id y campos clave>

PASO 1 — CLASIFICACIÓN DE NODOS
  <nodo>  →  [lectura / efecto / disparador]  →  (si efecto: ¿fija o añade/modifica-relativo?)
  ...

PASO 2 — MODOS DE FALLA POR EFECTO
  Para cada EFECTO, marcar cuáles aplican:
  [ ] Fallo parcial:   ¿qué estado queda si se corta justo después?
  [ ] Doble disparo:   ¿qué duplica al ejecutarse dos veces?
  [ ] Orden alterado:  ¿depende de que otro evento haya pasado antes?
  [ ] Cambio esquema:  ¿qué campos lee y qué pasa si cambian de forma?

PASO 3 — PREDICCIÓN DE DOBLE DISPARO (punta a punta)
  Si el evento entra dos veces, el estado final es: <una frase>

PASO 4 — TABLA DE RIESGO (ordenada por reversibilidad/costo, la peor arriba)
  # | Nodo | Tipo | Modo | Consecuencia | Gravedad
  --+------+------+------+--------------+---------

CLAVE DE DEDUPLICACIÓN CANDIDATA: <qué campo identifica el evento>

Fíjate en dos líneas que agregué al método básico y que valen oro en la práctica. En el paso 1, anotar si un efecto fija un valor o lo añade/modifica en relativo —la distinción de la lección 7— porque es lo que separa un efecto ya-idempotente de uno peligroso, y es fácil de pasar por alto. Y al final, la clave de deduplicación candidata: aunque la protección sea del Módulo 2, identificar desde ya qué campo (normalmente el event_id) servirá para reconocer el duplicado te ahorra medio módulo de trabajo después. Una auditoría que ya nombró la clave es una auditoría que le dejó el terreno listo a la solución.

Una recomendación de uso: llena la plantilla antes de tocar el workflow, no después. El momento ideal para auditar es cuando lo construyes o cuando lo heredas, con la cabeza puesta en entender, no en arreglar. Guarda la tabla resultante junto al workflow —en su descripción, en un documento del equipo— porque es la memoria de por qué el flujo está diseñado como está, y le sirve al próximo que lo toque, incluido tú en seis meses.

Los patrones que vas a ver una y otra vez

Después de auditar unos cuantos workflows, empiezas a notar que las tablas de riesgo se parecen. No es casualidad: los efectos peligrosos siguen patrones, y reconocerlos acelera cada auditoría siguiente. Estos son los que más se repiten, y vale la pena tenerlos como sospechosos habituales:

El efecto que mueve dinero es casi siempre el riesgo número uno. Cobrar, reembolsar, transferir: son los menos reversibles y los más costosos, así que dominan la parte alta de la tabla. En order-triage era Create charge; en subscription-billing era Create charge; en refund-handler de la lección 6 era Create refund. Cuando audites un flujo, busca primero dónde se mueve el dinero.

El fallo parcial justo después del efecto crítico es el riesgo número dos. Porque es el que convierte un fallo honesto en un duplicado vía el reintento de recuperación. Aparece pegado al efecto que mueve dinero, una y otra vez.

Las actualizaciones "update/sync/set" esconden la trampa fija-vs-relativo. Update stock, Update next_date: nombres neutros que pueden ser inofensivos (fijan un valor) o peligrosos (modifican en relativo). Son los riesgos escondidos más comunes, porque el diagrama no muestra la diferencia.

Las lecturas casi nunca están en la tabla, y eso está bien. En cada auditoría, una parte de los nodos son consultas que puedes soltar. Si tu tabla marca lecturas como riesgos, revisa: probablemente confundiste una lectura con un efecto, o encontraste un efecto disfrazado (que entonces sí va, pero como efecto).

El correo/notificación es un efecto real pero de baja gravedad. Un mensaje duplicado es molesto y poco costoso, así que suele cerrar la tabla por abajo. Real, pero rara vez urgente.

Estos patrones no reemplazan al método —siempre recorres los cuatro pasos— pero te dan intuición sobre dónde mirar primero y qué esperar. Un dueño del sistema experimentado audita rápido no porque se salte pasos, sino porque reconoce estos patrones y confirma con el método lo que ya sospecha.

Un caso que conviene tener presente: los flujos que no tienen efectos

No todo workflow necesita esta auditoría con la misma urgencia, y saber reconocer cuáles no es parte del criterio. Hay flujos que solo leen y transforman: consultan datos, los reordenan, los combinan, y entregan un resultado sin crear, cobrar, enviar ni borrar nada durable. Un workflow que arma un reporte a partir de consultas, por ejemplo, o uno que lee una lista y la filtra para mostrarla.

Para esos flujos, la auditoría de confiabilidad tiene una respuesta corta y legítima: no hay riesgos de seguridad al fallar, porque no hay efectos que duplicar. Si el flujo se dispara dos veces, produce el mismo reporte dos veces, y un reporte repetido no daña nada —es una lectura de punta a punta—. Marcar todos los nodos como lecturas y cerrar la auditoría ahí no es pereza; es el resultado correcto.

Esto importa por dos razones. Primera, te evita gastar esfuerzo protegiendo lo que no lo necesita: no todo workflow es order-triage, y tratar un flujo de solo lectura como si moviera dinero es sobreingeniería. Segunda, afila tu radar para el caso mixto: la mayoría de los flujos reales combinan tramos de lectura con uno o dos efectos, y la auditoría te enseña a soltar los tramos de lectura y concentrar toda la atención en esos pocos efectos. La habilidad no es proteger todo; es distinguir, rápido, qué merece protección de qué no.

Con eso cerramos la idea que abrió el módulo: la mentalidad de dueño no es desconfiar de todo, es saber exactamente de qué desconfiar. Y una auditoría bien hecha es esa desconfianza convertida en un documento que cualquiera puede leer.

Cómo se ve una auditoría bien hecha

Vale la pena nombrar qué separa una buena auditoría de una superficial, porque el método se puede seguir bien o mal.

Nombra el mecanismo, no solo el síntoma. "Puede cobrar dos veces" es un síntoma. "Si el proveedor reintenta por no recibir confirmación, n8n crea dos ejecuciones y Create charge cobra en las dos" es el mecanismo. La segunda demuestra que entendiste por qué, y es la que convence en una entrevista.

Distingue lo seguro de lo peligroso. Una auditoría que marca todos los nodos como riesgosos no auditó, se asustó. La buena auditoría dice con claridad "esta lectura es segura, no la toques" tanto como "este efecto es crítico". Saber qué no proteger es tan valioso como saber qué proteger.

Encuentra al menos un riesgo escondido. Los riesgos obvios —"cobrar dos veces es malo"— los ve cualquiera. El valor de una auditoría está en los que no saltan: el Update next_date relativo, el efecto disfrazado de lectura, la dependencia de orden entre dos eventos. Si tu auditoría solo tiene lo obvio, recorre los cuatro modos otra vez, más despacio.

Prioriza de verdad. Una lista de riesgos sin orden obliga al lector a priorizar por su cuenta. Una lista ordenada por reversibilidad le dice "empieza por aquí". La priorización es parte del trabajo, no un adorno.

Errores comunes

Clasificar los nodos después de buscar los riesgos, o saltarse la clasificación (práctico). Qué pasa: alguien va directo a "¿dónde puede fallar?" sin marcar primero lecturas y efectos, y termina evaluando modos de falla sobre lecturas —perdiendo tiempo— o pasando por alto un efecto escondido. Por qué pasa: el impulso es buscar peligros de inmediato. Cómo detectarlo: si tu auditoría analiza fallos en un nodo que es una lectura pura, invertiste el orden. Cómo corregirlo: clasifica primero (paso 1), siempre. La clasificación es el filtro que te dice sobre qué nodos vale la pena recorrer los cuatro modos. Sin ese filtro, auditas a ciegas.

Detenerse en el primer riesgo grave (práctico). Qué pasa: se encuentra el cobro duplicado, se siente que "ese es el problema", y se termina la auditoría ahí. Se pierden el fallo parcial, el Update next_date relativo, el cambio de esquema. Por qué pasa: el riesgo crítico es tan llamativo que parece agotar el tema. Cómo detectarlo: si tu tabla tiene una sola fila, no terminaste. Cómo corregirlo: el método es exhaustivo a propósito —recorre los cuatro modos sobre cada efecto—, precisamente para que el riesgo más llamativo no tape a los demás. Un cobro duplicado es urgente, pero un cliente que se salta un cobro por una fecha mal avanzada también cuesta dinero.

Confundir la auditoría con la solución (conceptual). Qué pasa: se hace la auditoría y se cree que el workflow ya está más seguro por el solo hecho de haberlo analizado. Por qué pasa: ver el problema con claridad da una sensación de control que se parece a haberlo resuelto. Cómo detectarlo: si después de auditar no cambiaste ni un nodo, el workflow es exactamente igual de frágil que antes. Cómo corregirlo: la auditoría es el diagnóstico indispensable, pero la reparación son los módulos siguientes. Su valor es que te dice qué reparar y en qué orden, para no gastar esfuerzo en lo que no importa. Es el mapa, no el viaje.

Auditar por intuición en vez de por método (práctico). Qué pasa: alguien con experiencia "ve" los riesgos de un vistazo y se salta los cuatro pasos, y funciona para los flujos que se parecen a los que ya conoce, pero falla con uno nuevo o raro. Por qué pasa: la intuición es rápida y a menudo acierta, lo que da confianza excesiva. Cómo detectarlo: si no podrías explicarle a alguien más cómo llegaste a tu lista de riesgos, fue intuición, no método. Cómo corregirlo: usa el método incluso cuando creas que no lo necesitas. La intuición encuentra lo que ya conoces; el método encuentra lo que no esperabas, que es justo donde viven los incidentes de producción.

Ejercicios

Ejercicio 1 — Audita inventory-sync por tu cuenta. Este workflow de Cumbre sincroniza el inventario cuando llega un pedido: descuenta el stock de los productos pedidos y, si algún producto queda por debajo del mínimo, crea una orden de reposición al proveedor. Haz la auditoría completa —los cuatro pasos— y entrega la tabla de riesgo.

Webhook          →  Get product     →  Update stock         →  Check threshold  →  Create restock order
(recibe el         (lee el stock      (descuenta las           (evalúa si el       (POST al proveedor si
 pedido)            actual del CRM)    unidades pedidas)        stock < mínimo)     hace falta reponer)

Ver solución

Paso 1 — clasificación:

Nodo	¿Repetirlo cambia el mundo?	Tipo
Webhook	Entrada	Disparador
Get product	No	Lectura
Update stock	Sí, y de forma relativa (descuenta)	Efecto peligroso
Check threshold	No: solo evalúa una condición	Lectura (un cálculo, no cambia el estado)
Create restock order	Sí: crea una orden	Efecto

Pasos 2 y 3 — modos y predicción de doble disparo. El nodo más peligroso es Update stock, porque es una actualización relativa ("descuenta las unidades pedidas"), que como viste en la lección 7 NO es idempotente. Si el pedido se procesa dos veces, el stock se descuenta dos veces: se restan el doble de unidades de las que de verdad se vendieron. Eso puede llevar el inventario a un número falso y disparar una reposición innecesaria. Además, Create restock order duplicado crea dos órdenes al proveedor.

Predicción de doble disparo de punta a punta: el stock se descuenta dos veces (inventario falso, demasiado bajo) y posiblemente se crean dos órdenes de reposición que le costarán a Cumbre comprar producto que no necesita.

Paso 4 — tabla de riesgo:

#	Nodo	Tipo	Modo	Consecuencia	Gravedad
1	Update stock	Efecto	Doble disparo	Stock descontado el doble; inventario falso	Crítica
2	Create restock order	Efecto	Doble disparo	Dos órdenes de compra al proveedor	Alta
3	Update stock	Efecto	Fallo parcial	Descontado sin evaluar reposición	Media
4	Create restock order	Efecto	Cambio de esquema	Orden con cantidades incorrectas	Media
—	Get product, Check threshold	Lectura	—	Seguras de repetir	Ninguna

Por qué funciona: el corazón de esta auditoría es reconocer que Update stock es una actualización relativa y por tanto peligrosa de repetir, aunque su nombre ("update") suene tan inocente como el Update next_date del ejemplo. Si lo marcaste como efecto crítico por ser relativo, aplicaste bien la lección 7. Y si viste que Check threshold es una lectura —solo evalúa, no cambia nada— ahorraste el esfuerzo de auditarlo como efecto.

Ejercicio 2 — Encuentra el efecto disfrazado. En el workflow inventory-sync del ejercicio anterior, ¿hay algún nodo cuyo nombre sugiera que es una lectura pero que en realidad, por lo que hace, sea un efecto o esconda un riesgo? Explica.

Ver solución

Check threshold es el candidato a examinar, y la respuesta honesta es "depende de qué hace exactamente". Tal como está descrito —"evalúa si el stock está por debajo del mínimo"— es una lectura pura: solo compara dos números y decide un sí o un no, sin cambiar nada. En ese caso, no es un efecto.

Pero fíjate en la trampa potencial: si Check threshold estuviera implementado como "verifica el stock y, si está bajo, marca el producto como 'reposición pendiente' en el CRM", entonces esa marca sería un efecto escondido detrás de un verbo de lectura ("check"), igual que el "verifica y luego crea" de la lección 7. El nombre no basta para decidirlo; hay que mirar qué deja en el mundo.

El verdadero efecto disfrazado del flujo, sin embargo, es Update stock. "Update" suena neutro, casi administrativo, pero es la operación más peligrosa del workflow por ser una resta relativa. La lección es la misma: no clasifiques por el nombre, clasifica por lo que la operación deja en el mundo al terminar.

Por qué funciona: entrena el ojo para no confiar en los nombres. "Check", "update", "sync", "process" son verbos ambiguos que pueden esconder efectos. La prueba de la repetición aplicada al comportamiento real —no al nombre— es lo único que no se deja engañar.

Ejercicio 3 — Audita un workflow tuyo y defiéndelo. Toma un workflow real que hayas construido —o el que analizaste en la lección 2— y hazle la auditoría completa de cuatro pasos, entregando la tabla de riesgo. Después, escribe en cuatro o cinco frases la "defensa de entrevista": qué le dirías a alguien que te pregunta "¿es seguro poner esto en producción?".

Ver solución

No hay una respuesta única porque depende de tu workflow, pero sí un patrón de lo que constituye una buena entrega.

La tabla de riesgo debería tener: cada nodo clasificado como lectura o efecto; para cada efecto, los modos de falla que lo golpean con su consecuencia concreta; una predicción del doble disparo de punta a punta; y un orden por gravedad usando reversibilidad. Si tu workflow no tiene efectos —solo lee y transforma— tu auditoría correcta es "no hay riesgos de seguridad al fallar, porque no hay efectos que duplicar", y eso también es un resultado válido y valioso.

La defensa de entrevista debería sonar parecida a esto (adaptado a tu caso): "El workflow es correcto en el caso normal, pero tiene [N] efectos, de los cuales [el más grave] es el riesgo principal: si se dispara dos veces —por un reintento del proveedor o de n8n— [consecuencia concreta]. También hay un fallo parcial posible entre [nodo A] y [nodo B] que un reintento convertiría en duplicado. La lectura [nodo] es segura y no necesita protección. Empezaría por proteger [el efecto crítico] con una clave de idempotencia sobre [el identificador del evento]."

Por qué funciona: si pudiste producir la tabla y la defensa, tienes la capacidad de salida del módulo. Fíjate en lo que cambió desde la lección 1: entonces mirabas un workflow y veías "funciona"; ahora miras el mismo workflow y ves su mapa de riesgo priorizado, y puedes defenderlo con el mecanismo concreto de cada fallo. Eso es dejar de ser solo constructor. La reparación de esos riesgos es lo que empieza en el Módulo 2, pero el diagnóstico —la mitad del trabajo— ya lo dominas.

Resumen y siguiente paso

En esta lección ensamblaste todo el módulo en una habilidad práctica: la auditoría de confiabilidad. Es un diagnóstico —no una reparación— que examina un workflow para encontrar dónde puede hacer daño al fallar o al repetirse, y lo anota de forma ordenada. Su método son cuatro pasos: clasificar cada nodo como lectura o efecto (lección 7), recorrer los cuatro modos de falla sobre cada efecto (lección 6), predecir el doble disparo de punta a punta (lecciones 4 y 5), y armar una tabla de riesgo ordenada por reversibilidad (lección 3). Su entregable es esa tabla de riesgo por nodo, que dice en treinta segundos dónde está el peligro y por dónde empezar.

Lo aplicaste a subscription-billing —un flujo que no habías visto— y produjiste una tabla priorizada que ubicó el cobro duplicado como riesgo crítico y sacó a la luz un riesgo escondido: el Update next_date relativo, invisible en el diagrama. Viste qué separa una buena auditoría de una superficial: nombrar el mecanismo y no solo el síntoma, distinguir lo seguro de lo peligroso, encontrar al menos un riesgo escondido, y priorizar de verdad.

Con esto cierras el Módulo 1. La capacidad que te llevas es concreta y verificable: puedes tomar cualquier workflow, tuyo o ajeno, y decir con precisión dónde puede duplicar un efecto, dónde un reintento hace daño y qué pasa si el disparador llega dos veces. Eso es, exactamente, ver el problema con los ojos del dueño del sistema en vez de los del constructor. Y ver el problema con claridad es la condición para resolverlo bien.

Lo que sigue es la reparación. El Módulo 2 toma el riesgo número uno de todas tus auditorías —el efecto que duplica al repetirse— y te enseña a hacerlo idempotente: qué es exactamente una clave de idempotencia, cómo elegir entre una natural y una sintética, cómo hacer idempotente una llamada a una API, y por qué "verificar y luego actuar" —el instinto que ya te advertí en la lección 4— es una trampa. Empiezas a convertir las tablas de riesgo que ahora sabes producir en workflows que ya no cobran dos veces.

Recursos

• Executions — n8n Docs — la herramienta con la que confirmas, sobre un workflow real, los riesgos que tu auditoría predice: cuántas ejecuciones hubo, dónde se cortaron, qué datos llevaban.
• HTTP Request node — n8n Docs — el nodo detrás de casi todos los efectos que vas a auditar; su método (GET vs POST/PUT/PATCH/DELETE) es tu primera pista de clasificación en el paso 1.
• Error handling — n8n Docs — el conjunto de herramientas para el fallo; útil para empezar a mapear, desde ya, qué defensa de n8n corresponde a cada riesgo de tu tabla, aunque las apliques recién en los módulos siguientes.
• Idempotence — referencia general — el concepto que da nombre a la reparación que empieza en el Módulo 2; conviene tenerlo fresco al cerrar el diagnóstico y abrir la solución.