3. Qué significa 'confiable' de verdad

Descripción

Al terminar esta lección vas a poder usar la palabra "confiable" con precisión, en lugar de como un elogio vago. Vas a distinguir tres propiedades que la gente mezcla todo el tiempo —que un sistema sea correcto, que esté disponible y que sea seguro al fallar— y vas a entender por qué la tercera es la que esta guía persigue y las otras dos, aunque importan, son de otras guías. Sobre todo, vas a llevarte el criterio con el que juzgaremos cada workflow de aquí en adelante: la diferencia entre "no falla" y "no hace daño al fallar".

Esto importa porque "confiable" es una de esas palabras que todos usan y casi nadie define, y esa vaguedad cuesta dinero. Cuando alguien dice "necesito que este workflow sea confiable", puede querer decir tres cosas muy distintas, y si construyes para la que no era, entregas algo que técnicamente cumple y en la práctica falla. Volver preciso el término es lo que te permite decir, frente a un workflow concreto, exactamente qué propiedad tiene y cuál le falta.

Conexión con el módulo: en la lección 2 aprendiste las tres preguntas del dueño del sistema, y viste que las tres eran variaciones de una sola preocupación: "no basta con que funcione, tiene que no hacer daño cuando no funciona". Esta lección convierte esa frase en un criterio técnico. Aquí separas las tres propiedades que se esconden dentro de la palabra "confiable" y decides cuál es la que esta guía diseña. A partir de la lección 4 vamos a la mecánica —cómo ejecuta n8n, por qué se producen los duplicados— y ese criterio es la vara con la que vas a medir si un flujo es seguro. La distinción entre lectura y efecto de la lección 7 es, en el fondo, una aplicación directa de lo que aprendes aquí.

"Confiable" no es una cosa, son tres

Empecemos por desarmar la palabra, porque adentro tiene tres ideas que conviene no mezclar.

Piensa en un cajero automático, ese de la esquina que usas para sacar dinero. ¿Qué significaría que ese cajero sea "confiable"? Fíjate que puede significar tres cosas distintas, y que las tres son deseables pero no son la misma:

Que te dé el monto correcto. Si pides mil y te da mil, el cajero es correcto. Si pides mil y te da novecientos, o te descuenta mil doscientos de tu cuenta, es incorrecto, aunque haya funcionado sin errores visibles. La correctitud es sobre si el resultado es el que debía ser.

Que esté funcionando cuando lo necesitas. Si llegas a las tres de la mañana y el cajero está encendido y operativo, está disponible. Si está apagado por mantenimiento, o "temporalmente fuera de servicio", no está disponible, por más correcto que sea cuando funciona. La disponibilidad es sobre si el sistema responde cuando lo buscas.

Que, cuando algo salga mal, no te haga daño. Esta es la más sutil y la más importante para nosotros. Imagina que el cajero se traba a la mitad de una operación: la pantalla se congela justo después de que pediste tu dinero. ¿Qué prefieres que pase? Que no te dé el dinero pero tampoco te lo descuente —un fallo limpio, del que te recuperas volviéndolo a intentar—, o que te descuente el dinero de la cuenta pero no te lo entregue por la ranura —un fallo que te hizo daño—. Un cajero seguro al fallar es uno diseñado para que, cuando se traba, no te cobre sin darte el dinero. Esta propiedad no es sobre si falla o no; es sobre qué pasa cuando falla.

Las tres juntas forman lo que la gente llama "confiable". Pero son propiedades separadas: un sistema puede ser correcto y no estar disponible (funciona bien pero está caído la mitad del tiempo), puede estar disponible y ser incorrecto (siempre responde, pero con datos malos), y —esto es lo clave— puede ser correcto y estar disponible y aun así no ser seguro al fallar, que es exactamente el caso de order-triage.

Correcto vs disponible: dos propiedades del caso normal

Antes de llegar a la propiedad que nos importa, separemos bien las dos primeras, porque se confunden seguido.

Correcto significa que el resultado es el que debía ser, dado que todo funcionó. order-triage es correcto si, cuando procesa un pedido, registra el pedido bien, cobra el monto exacto y manda el correo al cliente correcto. La correctitud es responsabilidad del constructor de la lección 2: se verifica ejecutando el workflow con datos buenos y revisando que el resultado sea el esperado.

Disponible significa que el sistema está operativo cuando algo lo necesita. Un order-triage disponible es uno cuya instancia de n8n está encendida, cuyo webhook responde, cuyos servicios de destino contestan. La disponibilidad depende de cosas como el servidor donde corre n8n, la red, y el estado de los servicios externos. Es, en gran medida, un problema de operación e infraestructura.

Y aquí una frontera importante de esta guía, que conviene declarar temprano: la disponibilidad no es nuestro tema. Mantener n8n encendido, escalar la infraestructura, monitorear que los servicios respondan, poner reintentos automáticos cuando algo está caído —todo eso es operación en producción, y es una guía distinta del ecosistema—. No porque no importe; importa muchísimo. Sino porque esta guía se ocupa de otra cosa, y mezclar las dos hace que ninguna quede clara.

¿De qué se ocupa esta guía, entonces? De la tercera propiedad.

Seguro al fallar: la propiedad que esta guía diseña

Esta es la propiedad central, y merece una definición que puedas repetir de memoria:

Un workflow es seguro al fallar si, cuando algo sale mal —un servicio se cae, un disparo se repite, un dato viene raro— el sistema no queda en un estado peor que si nada hubiera pasado.

Fíjate en lo que esta definición no dice. No dice "un workflow seguro nunca falla". Los fallos son inevitables: los servicios externos se caen, las redes parpadean, los proveedores reintentan. Pedirle a un workflow que nunca falle es pedirle que controle cosas que no controla. Lo que sí puedes controlar —y es lo que la definición pide— es qué queda después del fallo.

Volvamos al cajero. Un cajero seguro al fallar no es uno que nunca se traba; es uno que, cuando se traba, no te descuenta sin darte el dinero. El fallo ocurre igual. La diferencia está en el estado que deja: uno limpio (ni dinero ni cargo) del que te recuperas fácil, o uno dañino (cargo sin dinero) que hay que reparar a mano.

order-triage, hoy, no es seguro al fallar. Ya viste por qué en la lección 2: si se dispara dos veces, cobra dos veces; si un servicio cae a la mitad y se reintenta, cobra dos veces. En los dos casos, después del incidente el sistema queda peor que si nada hubiera pasado —hay un cobro de más que alguien tiene que reembolsar—. Ese "peor" es exactamente lo que la seguridad al fallar evita.

La diferencia entre "no falla" y "no hace daño al fallar"

Esta distinción es tan central que quiero dedicarle su propio espacio, porque es el corazón de la mentalidad de esta guía.

Hay dos formas de pensar la confiabilidad, y llevan a diseños muy distintos.

La primera es perseguir que nada falle. Poner más validaciones, más reintentos, más comprobaciones, con la meta de que el workflow nunca tropiece. Es una meta noble y en parte alcanzable, pero tiene un techo: por más que te esfuerces, no controlas si el servicio de correo se cae, ni si el proveedor reintenta, ni si la red parpadea. Siempre va a haber fallos que no puedes prevenir. Un diseño que apuesta todo a "que no falle" es frágil, porque el día que falle —y va a fallar— no tiene plan.

La segunda es aceptar que va a fallar y diseñar para que el fallo no haga daño. En lugar de gastar toda la energía en prevenir el tropiezo, gastas parte en asegurarte de que, cuando tropiece, no rompa nada. Un cobro que se puede repetir sin cobrar de más. Un registro que se puede crear dos veces sin duplicarse. Un correo que, si se reintenta, no se manda doble. Este diseño es robusto, porque no depende de que la suerte esté de tu lado.

La ingeniería de sistemas confiables se apoya sobre todo en la segunda. No porque la primera sea mala —prevenir fallos es bueno— sino porque la primera sola no alcanza, y la segunda es la que te salva cuando la primera falla. Podríamos decirlo así: prevenir el fallo es deseable; sobrevivir al fallo sin daño es indispensable.

Y esto conecta directamente con la palabra que da nombre a la guía. Hacer que un efecto se pueda repetir sin hacer daño tiene un nombre técnico —idempotencia— y es el tema del Módulo 2. Toda la idempotencia es una forma de seguridad al fallar: es la técnica concreta que hace que repetir un cobro no cobre de más. Por eso esta lección es la base conceptual sobre la que se para todo lo demás.

Ejemplo trabajado: dos versiones que "funcionan", solo una es segura

Vamos a comparar dos versiones de un fragmento de order-triage, para que la diferencia entre "funciona" y "es seguro al fallar" deje de ser abstracta.

Las dos versiones cobran el pedido. Las dos, en la demo, producen exactamente el mismo resultado: un cobro correcto por el monto correcto. Un constructor las aprobaría a las dos.

Versión A — cobra directo. El nodo Create charge recibe el pedido y llama a la pasarela para cobrar amount. Es lo más simple y es lo que sale natural.

... ──►  Create charge
         POST /charges
         body: { customer_id, amount, currency }

Versión B — cobra con una clave que identifica el cobro. El mismo nodo, pero le agrega a la petición un dato extra: una clave única que identifica este cobro específico, derivada del pedido.

... ──►  Create charge
         POST /charges
         body: { customer_id, amount, currency }
         header: Idempotency-Key: charge_ORD-2041

Qué esperar en la demo. Idénticas. Le mandas un pedido a cada versión, las dos cobran $2154 una vez, el panel muestra un cobro exitoso en ambas. Si solo pruebas el camino feliz, no hay forma de distinguirlas. Por eso el problema es traicionero: la versión insegura se ve igual de bien que la segura hasta el día que algo se repite.

Qué esperar cuando el pedido llega dos veces. Aquí se separan. La versión A, al recibir el segundo disparo, manda otra petición de cobro sin ninguna marca de que es el mismo, y la pasarela —que no tiene forma de saberlo— cobra otra vez. Dos cargos. La versión B manda la segunda petición con la misma Idempotency-Key: charge_ORD-2041, y una pasarela que respeta esa clave reconoce "ya procesé un cobro con esta clave" y devuelve el resultado del primero sin cobrar de nuevo. Un solo cargo, aunque la petición llegó dos veces.

No te preocupes por los detalles de cómo funciona la clave —eso es el Módulo 2 completo—. Lo único que quiero que veas es que las dos versiones son igual de correctas y estuvieron igual de disponibles; la única diferencia es que la B es segura al fallar y la A no. Y esa diferencia, invisible en la demo, es toda la diferencia el día del incidente.

Fíjate también en una cosa que vamos a repetir mucho: la seguridad al fallar casi nunca se ve en el resultado normal. Se ve solo cuando algo sale mal. Por eso no se puede verificar con la prueba del constructor —ejecutar una vez y ver que sale bien— y por eso hace falta un método distinto para auditarla, que es lo que construyes en la lección 8.

Por qué la disponibilidad y la seguridad al fallar tiran en direcciones distintas

Un matiz que vale la pena entender, porque explica muchas decisiones de diseño que verás en la guía.

La disponibilidad te empuja a reintentar: si un servicio no responde, inténtalo de nuevo, porque quieres que el trabajo se complete. Es la respuesta natural a un fallo cuando lo que te importa es que las cosas sucedan.

La seguridad al fallar te obliga a preguntar antes de reintentar: ¿es seguro repetir esto? Porque si el reintento vuelve a ejecutar un efecto que ya se hizo, la búsqueda de disponibilidad crea un daño. Ya lo viste en la línea de tiempo de la lección 2: reintentar el workflow completo para arreglar un correo terminó cobrando dos veces.

Las dos preocupaciones no se contradicen, pero hay que reconciliarlas, y el orden importa: primero haces los efectos seguros de repetir, después reintentas con confianza. Un reintento sobre efectos idempotentes es una herramienta poderosa; un reintento sobre efectos no protegidos es una máquina de duplicar. Esta es la razón por la que el Módulo 2 (idempotencia) viene antes del Módulo 6 (reintentos): no puedes reintentar bien hasta que repetir sea seguro.

La palabra que une todo: el estado del sistema

Habrás notado que la definición de "seguro al fallar" se apoya en una palabra que no definimos: estado. Vale la pena detenerse en ella, porque es el concepto que conecta esta lección con el resto de la guía, sobre todo con el Módulo 4.

El estado del sistema es todo lo que queda escrito en algún lado después de que un workflow corre. No los datos que fluyen de nodo en nodo durante la ejecución —esos son pasajeros, desaparecen cuando la ejecución termina— sino las huellas durables que quedan afuera: el registro en el CRM, el cobro en la pasarela, el correo en la bandeja del cliente, una fila en una base de datos. El estado es la memoria del mundo sobre lo que tu workflow hizo.

Piénsalo como la diferencia entre lo que dices en una conversación y lo que firmas en un papel. Lo que dices se lo lleva el aire; el papel firmado queda. Un workflow habla mucho por dentro —los items viajando— pero solo "firma papeles" cuando hace un efecto: crear, cobrar, enviar. Esos papeles son el estado.

Con esa palabra, la definición de seguridad al fallar se vuelve más nítida:

Un workflow es seguro al fallar si un fallo no deja el estado peor que antes. Es decir: si al terminar, con o sin fallo, con una o con dos ejecuciones, los papeles firmados son los que debían ser —ni uno más, ni uno menos—.

Un cobro duplicado es un papel de más. Un correo no enviado por un fallo parcial es un papel de menos. Los dos son estados incorrectos, y el trabajo del dueño del sistema es que el estado final sea el correcto sin importar cuántas veces se disparó el flujo ni dónde se cayó.

Aquí aparece una pregunta que la guía va a perseguir varias veces: para saber si un pedido "ya dejó su papel", el sistema tiene que poder consultar el estado. Si no hay ningún lugar donde esté escrito "el pedido ORD-2041 ya se cobró", no hay forma de que la segunda ejecución lo sepa. Por eso el Módulo 4 se llama "el modelo de datos del sistema" y trata sobre construir ese lugar durable donde vive la verdad. La seguridad al fallar, en el fondo, necesita que el sistema tenga memoria de su propio estado. Por ahora, quédate con la palabra: cada vez que digamos "estado", nos referimos a las huellas durables que un workflow deja en el mundo.

No todo daño pesa lo mismo: reversibilidad

Hay un matiz más que conviene tener desde ahora, porque afina el criterio y prepara el terreno para el Módulo 6. Cuando un fallo deja el sistema "peor", ese "peor" no siempre tiene la misma gravedad. Lo que decide la gravedad es qué tan fácil es deshacer el daño.

Piensa en la diferencia entre derramar agua y romper un vaso. El agua se seca; el vaso roto no se rearma. Los dos son accidentes, pero uno es reversible y el otro no, y por eso reaccionamos distinto ante cada uno.

Los efectos de un workflow tienen esa misma escala. Vale la pena verla ordenada, porque cambia cuánto te preocupa cada duplicado:

Efecto duplicado	¿Se puede deshacer?	Qué tan grave
Un registro duplicado en el CRM	Sí, borrando uno de los dos	Molesto, se limpia
Un correo enviado dos veces	No —el correo ya salió— pero el daño es leve	Incómodo, rara vez costoso
Un cobro duplicado	Sí, con un reembolso, pero cuesta dinero, tiempo y confianza	Grave
Un mensaje enviado a un cliente equivocado	No, y puede ser reputacional o legal	Muy grave

Fíjate en algo importante: la seguridad al fallar importa más cuanto menos reversible es el efecto. Un registro duplicado en el CRM se limpia en un minuto; un cobro duplicado te cuesta un reembolso y una llamada de un cliente molesto; un mensaje mal enviado puede no tener vuelta atrás. Por eso, cuando priorices qué proteger primero —y en un sistema real siempre priorizas— empiezas por los efectos menos reversibles y más costosos.

Hay un matiz que conviene no perder: "reversible" no siempre significa "gratis de revertir". Un cobro duplicado se puede revertir con un reembolso, así que técnicamente es reversible, pero revertirlo cuesta dinero, tiempo del equipo, y un pedazo de la confianza del cliente que no se recupera con el reembolso. Cuando ordenes por gravedad, no pienses solo en "¿se puede deshacer?" sino en "¿cuánto cuesta deshacerlo, y qué queda dañado aunque lo deshaga?". Un cargo devuelto borra el monto de la tarjeta, pero no borra la mala experiencia del cliente que vio dos cobros y tuvo que reclamar. Esa parte —la confianza— es el daño verdaderamente irreversible de muchos efectos que en el papel parecen reversibles.

Esta escala también explica una decisión del Módulo 6: no todo fallo merece una alerta. Un fallo que deja el sistema limpio y que se recupera solo con un reintento seguro no necesita despertarte; un fallo que produjo un cobro duplicado sí. La gravedad de la alerta debe seguir la gravedad del daño, y la gravedad del daño la mide la reversibilidad. Por ahora quédate con la idea: cuando busques dónde poner tu esfuerzo, ordénalo por qué tan difícil es deshacer el daño.

El criterio que la guía va a usar

Con todo lo anterior, ya podemos escribir la vara con la que vamos a medir cada workflow del resto de la guía. Cuando mires un flujo y quieras saber si es confiable en el sentido que nos importa, hazte estas preguntas, en este orden:

1. ¿Es correcto? Con datos buenos y una sola ejecución, ¿hace lo que debe? (Trabajo del constructor.)
2. ¿Qué efectos tiene? ¿Qué operaciones crean, cobran, envían o borran algo? (Lección 7.)
3. ¿Cada efecto es seguro de repetir? Si el workflow se dispara dos veces, o se reintenta después de un fallo parcial, ¿cada efecto queda igual que si hubiera pasado una sola vez? (El resto de la guía.)

La primera pregunta la resuelve lo que ya sabes. La segunda la resuelves con la distinción de la lección 7. La tercera es la que define si el sistema es seguro al fallar, y es la que la guía te enseña a responder que sí. Un workflow que responde "sí" a la tercera para todos sus efectos es lo que esta guía llama confiable. No uno que nunca falla —eso no existe— sino uno que, cuando falla, no deja el sistema peor.

Fíjate en el orden, porque no es casual. La correctitud va primero porque no tiene sentido hacer seguro de repetir algo que ni siquiera hace lo correcto la primera vez —blindarías un error para que se repita sin daño, lo cual no sirve de mucho—. Después identificas los efectos, porque solo ellos necesitan la tercera pregunta: proteger una lectura es esfuerzo desperdiciado. Y recién entonces te preguntas por la seguridad de repetir, efecto por efecto. Este orden es también el orden de la guía: primero das por hecho que sabes construir correcto (el piso que traes), luego aprendes a separar lecturas de efectos (lección 7), y luego dedicas cinco módulos a la tercera pregunta. Cuando el criterio te salga en este orden de forma automática, vas a poder auditar cualquier workflow en minutos.

Errores comunes

Confundir disponibilidad con seguridad al fallar (conceptual). Qué pasa: alguien invierte todo en que el workflow "no se caiga" —mejor infraestructura, más reintentos automáticos— y descubre que, aunque ahora se cae menos, cada vez que se recupera de un fallo con un reintento, cobra dos veces. Por qué pasa: las dos propiedades suenan parecido, y "reintentar hasta que funcione" parece la solución obvia a cualquier fallo. Cómo detectarlo: si tu estrategia de confiabilidad es reintentar y tus efectos no están protegidos, cada reintento es un duplicado potencial. Cómo corregirlo: separa las dos preocupaciones. La disponibilidad —que no se caiga— es de operación. La seguridad al fallar —que el reintento no haga daño— es de esta guía, y va primero: haz los efectos seguros de repetir antes de agregar reintentos.

Perseguir "que nunca falle" como estrategia principal (conceptual). Qué pasa: se llena el workflow de validaciones y comprobaciones con la meta de que nada tropiece nunca, y el día que un servicio externo se cae —algo que no controlas— el workflow no tiene ningún plan y hace daño. Por qué pasa: prevenir fallos es intuitivo y da sensación de control. Cómo detectarlo: pregúntate qué pasa en el peor caso que no puedes prevenir —el servicio de cobro se cae después de cobrar—. Si la respuesta es "no sé" o "duplica", tu diseño apuesta todo a la prevención. Cómo corregirlo: acepta que va a fallar y diseña para que el fallo no haga daño. Prevenir es bueno; sobrevivir sin daño es indispensable. La energía debe repartirse hacia la segunda.

Creer que "pasó la demo" prueba que es seguro al fallar (conceptual). Qué pasa: se prueba el workflow, sale bien, y se concluye que es confiable. Pero la demo prueba correctitud y disponibilidad en el caso normal, no seguridad al fallar, que solo se manifiesta cuando algo sale mal. Por qué pasa: la seguridad al fallar es invisible en el resultado normal; las versiones segura e insegura se ven idénticas hasta el incidente. Cómo detectarlo: si nunca probaste qué pasa con un disparo doble o un fallo parcial, no probaste la seguridad al fallar. Cómo corregirlo: la seguridad al fallar necesita su propia prueba —simular el disparo doble, simular el fallo entre dos efectos— que es distinta de la prueba del camino feliz. La lección 8 te da el método.

Usar "confiable" como elogio en vez de como criterio (conceptual). Qué pasa: se dice "este workflow es confiable" para decir "me gusta cómo quedó", sin especificar cuál de las tres propiedades tiene. Por qué pasa: la palabra es cómoda y suena bien. Cómo detectarlo: si al decir "confiable" no puedes contestar "¿correcto, disponible o seguro al fallar?", estás usando la palabra como adorno. Cómo corregirlo: cada vez que alguien —incluido tú— pida algo "confiable", tradúcelo a las tres propiedades y pregunta cuál importa aquí. Un flujo de reportes internos quizá solo necesita ser correcto; un flujo que cobra necesita las tres, y sobre todo la tercera.

Ejercicios

Ejercicio 1 — Clasifica cada fallo. Para cada situación con order-triage, di qué propiedad está comprometida: correctitud, disponibilidad o seguridad al fallar.

(a) La instancia de n8n está apagada por un corte de luz, y durante dos horas ningún pedido se procesa. (b) El nodo Create charge está cobrando amount sin convertir de dólares a pesos, así que todos los cobros salen con el número equivocado. (c) El workflow se disparó dos veces por un reintento del proveedor y cobró dos veces al mismo cliente. (d) El servicio de correo responde lento algunos días, y los correos de confirmación llegan con veinte minutos de retraso.

Ver solución

(a) Disponibilidad. El sistema no está operativo cuando se lo necesita. No hay nada incorrecto ni inseguro; simplemente no está encendido. Es un problema de operación e infraestructura, fuera del alcance de esta guía.

(b) Correctitud. El resultado no es el que debía ser: cobra el monto equivocado. El workflow está disponible y —en cierto sentido triste— es "seguro al fallar" porque no duplica, pero está mal. Es trabajo del constructor.

(c) Seguridad al fallar. Aquí está nuestro tema. El sistema quedó peor que si nada hubiera pasado —un cobro de más— como consecuencia de una repetición. Correcto en cada ejecución individual, disponible, pero inseguro al repetirse.

(d) Disponibilidad (parcial). El servicio responde, pero degradado. No es incorrecto —el correo llega, con el contenido correcto— ni inseguro. Es un problema de rendimiento y operación.

Por qué funciona: fíjate que solo (c) es de esta guía. Las otras tres son reales e importantes, pero pertenecen al constructor (b) o a la operación (a, d). Saber a qué categoría pertenece un problema es lo que te dice quién debe resolverlo y con qué herramientas.

Ejercicio 2 — Explica la diferencia con un ejemplo propio. Piensa en un sistema que uses a diario —un banco, una app de transporte, una tienda— e inventa dos versiones de un mismo fallo: una donde el sistema "no hace daño al fallar" y otra donde sí. Escribe las dos y explica qué las diferencia.

Ver solución

No hay una respuesta única. Un ejemplo típico con una app de transporte:

Fallo que no hace daño: pides un viaje, la app se congela, y cuando la reabres no hay ningún viaje pedido y no te cobraron nada. El fallo ocurrió, pero el estado quedó limpio: vuelves a pedir y listo.

Fallo que sí hace daño: pides un viaje, la app se congela, y cuando la reabres descubres que se pidieron dos viajes y te van a cobrar los dos. El fallo dejó el sistema peor que si nada hubiera pasado.

Lo que diferencia a las dos no es que una falle y la otra no —las dos se congelaron igual— sino qué quedó después. La primera está diseñada para que un fallo a la mitad no confirme el viaje; la segunda no, y por eso el reintento del usuario crea un duplicado.

Por qué funciona: si pudiste construir las dos versiones, internalizaste que la seguridad al fallar no es sobre evitar el fallo, sino sobre el estado que deja. Ese es el corazón del criterio de esta guía, y ahora lo tienes con un ejemplo que es tuyo.

Ejercicio 3 — Aplica el criterio de tres preguntas. Toma el nodo Create CRM order de order-triage, que crea un registro del pedido en el CRM. Aplícale el criterio de tres preguntas de esta lección: ¿es correcto?, ¿qué efecto tiene?, ¿es seguro de repetir? Responde cada una y di qué le falta para ser seguro al fallar.

Ver solución

¿Es correcto? Sí, asumiendo que está bien construido: con un pedido bueno y una sola ejecución, crea un registro con los datos correctos. Eso lo verifica el constructor.

¿Qué efecto tiene? Crea un registro. Es un efecto de tipo "crear": deja una huella durable en el CRM que no se deshace sola.

¿Es seguro de repetir? No, tal como está. Si el workflow se dispara dos veces, Create CRM order crea dos registros del mismo pedido. Al repetirse, el sistema queda peor: un registro duplicado que alguien tendrá que limpiar, y que además puede confundir a los reportes o al equipo de ventas.

Qué le falta. Le falta una forma de reconocer "este pedido ya lo registré". Podría ser una clave única —por ejemplo, basada en order_id— que el CRM use para no crear un segundo registro con el mismo pedido, o una verificación previa contra un lugar durable que recuerde qué pedidos ya se procesaron. Cuál de las dos y cómo hacerla bien es el contenido del Módulo 2 y el Módulo 4.

Por qué funciona: acabas de aplicar el criterio completo a un nodo concreto y a llegar, tú solo, a la forma de la solución —una clave que identifique el pedido— sin que nadie te la enseñara todavía. Eso es exactamente lo que la mentalidad de dueño te permite: mirar un efecto y saber qué le falta para ser seguro, aunque aún no domines la técnica.

Resumen y siguiente paso

En esta lección volviste preciso el término "confiable", que adentro esconde tres propiedades distintas. Un sistema es correcto si da el resultado que debía dar con datos buenos; está disponible si responde cuando lo necesitas; y es seguro al fallar si, cuando algo sale mal, no queda en un estado peor que si nada hubiera pasado. Las tres importan, pero se resuelven en lugares distintos: la correctitud es del constructor, la disponibilidad es de operación e infraestructura, y la seguridad al fallar es la propiedad que esta guía diseña.

El corazón de la lección fue la diferencia entre "no falla" y "no hace daño al fallar". Perseguir que nada falle tiene un techo, porque no controlas los servicios externos ni los reintentos de los proveedores. Aceptar que va a fallar y diseñar para que el fallo no haga daño es lo que produce sistemas robustos. Viste dos versiones de un cobro que en la demo son idénticas y solo se distinguen cuando el pedido llega dos veces —una cobra doble, la otra no— y entendiste que la seguridad al fallar es invisible en el caso normal, lo que la hace traicionera y obliga a un método de prueba propio.

Y te llevas el criterio de tres preguntas con el que vamos a juzgar cada workflow: ¿es correcto?, ¿qué efectos tiene?, ¿es seguro de repetir cada efecto?

Antes de avanzar deberías poder: nombrar las tres propiedades y dar un ejemplo de cada una; explicar en una frase la diferencia entre "no falla" y "no hace daño al fallar"; y aplicar el criterio de tres preguntas a un efecto concreto.

Ya tienes el criterio. Lo que falta es entender la mecánica que hace que los duplicados ocurran en primer lugar. La lección 4 abre el motor de n8n 2.0 y te muestra cómo ejecuta de verdad: qué es una ejecución, cómo fluye un item, qué pasa cuando reintentas, y por qué un reintento vuelve a ejecutar nodos. Sin esa mecánica, "seguro de repetir" es una idea abstracta; con ella, vas a ver exactamente el momento en que un efecto se repite.

Recursos

• Error handling — n8n Docs — el conjunto de herramientas que n8n ofrece para el fallo; leerlas con el criterio de esta lección te ayuda a distinguir cuáles atacan disponibilidad y cuáles seguridad al fallar.
• Executions — n8n Docs — dónde se ve el estado de cada ejecución (exitosa, fallida, en curso); la ventana desde la que observas si un fallo dejó el sistema limpio o dañado.
• What is idempotency? — glosario de n8n — la definición corta del concepto que da nombre a la guía y que, como viste, es la técnica concreta que hace un efecto seguro de repetir.
• Reliability engineering — referencia general — una entrada de referencia sobre la disciplina de diseñar sistemas confiables; útil para ver que la distinción entre prevenir el fallo y sobrevivir al fallo es un principio de ingeniería, no una idea exclusiva de n8n.