7. Lecturas vs efectos: qué operaciones son peligrosas al repetirse

Descripción

Al terminar esta lección vas a poder mirar cualquier nodo de cualquier workflow y clasificarlo en una de dos categorías: lectura o efecto. Vas a entender por qué una lectura se puede repetir todas las veces que quieras sin ninguna consecuencia, mientras que un efecto, al repetirse, hace daño. Y vas a llevarte la definición precisa de idempotencia —hacer que repetir un efecto sea seguro— con la que se abre el Módulo 2. Esta distinción es la bisagra sobre la que gira toda la guía: es lo que te dice, de un solo vistazo, cuáles nodos necesitan protección y cuáles puedes ignorar tranquilo.

Esto importa porque sin esta distinción, la mentalidad de dueño se vuelve agotadora y contraproducente. Si crees que todo nodo es peligroso, gastas esfuerzo protegiendo cosas que no lo necesitan, ensucias los workflows con candados inútiles y, peor, te distraes de los pocos puntos que sí importan. La distinción lectura/efecto es lo que hace la confiabilidad selectiva: en un workflow de seis nodos, quizá solo tres son efectos, y solo esos tres necesitan toda tu atención. Saber cuáles son es la mitad del trabajo.

Conexión con el módulo: esta es la lección bisagra del módulo. Todo lo anterior desemboca aquí. En la lección 3 dijimos que solo los efectos necesitan la pregunta "¿es seguro de repetir?"; aquí definimos qué es un efecto. En la lección 6 notaste que en los mapas de riesgo algunos nodos aparecían una y otra vez (Create charge) y otros casi nunca (Get customer); aquí está el principio que lo explica. Y todo lo que viene —la idempotencia del Módulo 2, los contratos del 3, el ledger del 4— opera sobre los efectos, nunca sobre las lecturas. La lección 8 usa esta distinción como el primer paso de la auditoría: antes de listar modos de falla, clasificas cada nodo, porque los modos de falla solo muerden en los efectos.

Dos clases de operaciones

Empecemos por la distinción, en su forma más simple, con una imagen que no vas a olvidar.

Piensa en la diferencia entre leer un termómetro y encender una estufa.

Leer el termómetro no cambia nada. Miras el número, sabes la temperatura, y el mundo queda exactamente igual que antes de mirar. Puedes leerlo una vez, diez veces, cien veces: la habitación no se calienta ni se enfría por el hecho de que la mires. La lectura es pasiva: toma información del mundo sin alterarlo.

Encender la estufa sí cambia algo. Giras la perilla y la habitación empieza a calentarse. Y aquí está la diferencia crucial: si giras la perilla dos veces —si repites la acción— no es lo mismo que girarla una. La segunda vez sube más la temperatura, o enciende un segundo quemador, o gasta más gas. La acción es activa: deja una huella en el mundo, y repetirla deja una huella mayor.

Esa es, exactamente, la diferencia entre una lectura y un efecto en un workflow:

Una lectura toma información sin cambiar el estado del sistema. Repetirla no tiene consecuencias. Un efecto cambia el estado del sistema —crea, cobra, envía, borra, modifica—. Repetirlo tiene consecuencias.

Recuerda la palabra "estado" de la lección 3: las huellas durables que quedan en el mundo. Una lectura no toca el estado; un efecto lo modifica. Toda la seguridad al fallar de la que hablamos —que un fallo o una repetición no deje el sistema peor— se juega enteramente en los efectos, porque solo ellos pueden dejar el sistema peor. Las lecturas son inofensivas por naturaleza.

Cómo reconocer cada una

La distinción es clara en el ejemplo del termómetro, pero en un workflow real necesitas reconocerla rápido. Hay dos señales prácticas que casi nunca fallan.

Señal 1: el verbo de la operación. Las operaciones suelen delatarse por lo que hacen. Fíjate en el verbo:

Verbos de lectura	Verbos de efecto
consultar, obtener, buscar, listar, leer, verificar, calcular	crear, cobrar, enviar, borrar, actualizar, insertar, publicar, reservar
get, list, fetch, search, read, lookup	create, charge, send, delete, update, insert, post, book

Si el nodo "obtiene la ficha del cliente", es lectura. Si "crea el registro", "cobra", "manda el correo", es efecto. El verbo casi siempre lo dice.

Señal 2: la prueba de la repetición. La más confiable. Hazte esta pregunta sobre el nodo:

Si ejecuto esta operación dos veces seguidas, ¿el resultado en el mundo es distinto de ejecutarla una sola vez?

Si la respuesta es no —el mundo queda igual—, es una lectura. Consultar la ficha del cliente dos veces deja el CRM idéntico: es lectura. Si la respuesta es sí —hay algo de más en el mundo—, es un efecto. Cobrar dos veces deja dos cargos: es efecto.

Esta prueba es más poderosa que el verbo, porque funciona incluso cuando el verbo engaña. Y a veces engaña, como vas a ver enseguida.

En términos de HTTP: los métodos que ya conoces

Si trabajas con nodos HTTP Request —y en esta guía lo harás mucho— hay un atajo, porque el propio protocolo HTTP distingue lecturas de efectos. No es una regla perfecta, pero es una guía fuerte:

• GET es, por diseño, una lectura. Pedir datos sin cambiar nada. Un GET bien hecho nunca debería alterar el estado.
• POST típicamente crea algo. Es el verbo de efecto por excelencia: POST /charges crea un cobro, POST /orders crea un pedido. Repetir un POST normalmente duplica.
• DELETE borra. Es un efecto, aunque tiene una particularidad que vemos abajo.
• PUT y PATCH actualizan. Son efectos, pero de una clase especial —a menudo más segura de repetir— que también vemos abajo.

Cuando veas un nodo HTTP Request en order-triage, mirar su método es la forma más rápida de intuir si es lectura o efecto. Get customer es un GET —lectura—; Create charge es un POST —efecto—.

El caso incómodo: efectos que ya son casi seguros de repetir

Aquí es donde la distinción se pone interesante, y donde separas a quien entendió el concepto de quien memorizó una tabla. No todos los efectos son igual de peligrosos al repetirse. Algunos, por su naturaleza, ya son casi seguros.

Compara dos efectos:

"Crea un pedido nuevo" (POST /orders). Cada vez que lo ejecutas, se crea otro pedido. Dos ejecuciones, dos pedidos. Es un efecto peligroso: repetir duplica.

"Marca el pedido ORD-2041 como pagado" (PATCH /orders/ORD-2041 { status: "paid" }). La primera ejecución cambia el estado de "pendiente" a "pagado". ¿Y la segunda? Vuelve a poner "pagado" sobre algo que ya estaba "pagado". El resultado es idéntico. Repetir esta operación no duplica nada: el pedido queda "pagado" hayas ejecutado una vez o diez.

Fíjate en la diferencia. La primera operación añade algo nuevo cada vez (un pedido más). La segunda fija un valor: lo pone en un estado concreto, y ponerlo ahí dos veces es lo mismo que ponerlo una. La primera es peligrosa de repetir; la segunda ya es segura, por su propia forma.

Esta segunda clase de operación —que fija un estado en vez de añadir uno nuevo— es, sin que lo hayamos nombrado todavía, idempotente por naturaleza. Y esto nos lleva justo a la definición central de la guía.

La definición: idempotencia

Ya tienes todo para entender la palabra que da nombre a la guía, así que definámosla con precisión:

Una operación es idempotente si ejecutarla dos veces (o más) deja el sistema en el mismo estado que ejecutarla una sola vez.

"Marca el pedido como pagado" es idempotente: el sistema queda igual con una ejecución o con cinco. "Crea un pedido nuevo" no es idempotente: cada ejecución añade un pedido más.

Y aquí está la idea que abre el Módulo 2, la que quiero que te lleves como la conclusión de todo el módulo:

La idempotencia no es solo una propiedad que algunas operaciones tienen y otras no. Es algo que puedes construir. Tomas un efecto que no es idempotente —cobrar— y lo transformas en uno que sí lo es —cobrar de forma que repetir el cobro no cobre de nuevo—.

Esa transformación es todo el Módulo 2. Ya viste un anticipo en la lección 3: la Idempotency-Key. Cuando le mandas a la pasarela un cobro con una clave única que identifica ese cobro, la pasarela reconoce la clave repetida y no cobra dos veces. Convertiste "crear un cobro" (no idempotente) en "crear el cobro identificado por esta clave" (idempotente). El efecto sigue existiendo; lo que cambió es que repetirlo dejó de hacer daño.

Con esto, la frase que resume la guía entera cobra su sentido completo:

Idempotencia = hacer que repetir un efecto sea seguro. Y como solo los efectos se repiten con consecuencias, la idempotencia es una técnica que se aplica a los efectos, nunca a las lecturas.

Ejemplo trabajado: clasificar los seis nodos de order-triage

Vamos a clasificar el flujo completo, aplicando la prueba de la repetición a cada nodo. Este es el ejercicio que abre toda auditoría.

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

Nodo	¿Repetirlo cambia el mundo?	Clasificación	¿Necesita protección?
Webhook	Es la entrada; no hace nada hacia afuera	Ni lectura ni efecto (es el disparador)	No, pero es donde llega el duplicado
Get customer	No: consultar la ficha diez veces la deja igual	Lectura	No
AI Agent	No crea registros, pero consume tokens cada vez	Caso especial (ver abajo)	Casi no; ver matiz
Create CRM order	Sí: cada vez crea otro registro	Efecto (crea)	Sí
Create charge	Sí: cada vez cobra otra vez	Efecto (cobra)	Sí, prioridad 1
Send Email	Sí: cada vez manda otro correo	Efecto (envía)	Sí

Qué esperar de esta clasificación. De seis nodos, solo tres son efectos que necesitan protección, y uno de ellos —Create charge— es la prioridad absoluta por ser el menos reversible. Los demás puedes soltarlos: Get customer es una lectura inofensiva, el Webhook es la entrada, y el AI Agent es un caso que merece un párrafo aparte.

Esta es la potencia de la distinción: acabas de reducir "protege el workflow" —una tarea vaga y grande— a "protege estos tres nodos, empezando por este uno" —una tarea concreta y acotada—. La confiabilidad dejó de ser un océano y se volvió tres puntos en un mapa.

El caso especial: el AI Agent y otras operaciones "costosas pero no duplicadoras"

El AI Agent merece atención porque no cae limpio en ninguna de las dos categorías, y entender por qué afina tu criterio.

¿Es una lectura? Casi. No crea ningún registro de negocio: clasificar el pedido no deja una huella durable en el CRM ni cobra nada. Desde el punto de vista del estado del sistema, ejecutarlo dos veces no duplica nada visible: el pedido queda clasificado igual (o casi igual, porque un modelo puede dar respuestas ligeramente distintas, pero no duplica).

¿Es un efecto? También, en un sentido acotado: cuesta. Cada ejecución del agente consume tokens del modelo, y eso es dinero. Ejecutarlo dos veces cuesta el doble. No duplica un efecto de negocio, pero sí duplica un gasto.

Entonces, ¿cómo lo tratamos? Con un matiz honesto: para la seguridad al fallar —que es el tema de la guía— el AI Agent se comporta como una lectura, porque repetirlo no deja el sistema en un estado incorrecto. No hay un "segundo cobro" ni un "segundo registro" que limpiar. Por eso no necesita la protección de idempotencia con la misma urgencia que Create charge. Pero para el costo, repetirlo sí importa, y por eso, cuando protejas el flujo contra duplicados, un beneficio secundario será dejar de pagar clasificaciones repetidas.

La lección general, que aplica a muchas operaciones, es esta: la pregunta clave no es "¿cuesta?" sino "¿repetirlo deja el estado incorrecto?". Una operación puede costar y aun así ser segura de repetir (el agente); y una operación puede ser barata y peligrosísima de repetir (mandar un correo cuesta casi nada, pero un correo duplicado a un cliente es un efecto real). No confundas el costo con el daño. El daño —dejar el estado peor— es lo que define un efecto peligroso.

Esta guía es sobre el daño. El costo es una preocupación legítima pero distinta, y muchas veces la solución al daño (deduplicar) resuelve el costo de paso.

Efectos que no parecen efectos

La prueba de la repetición es infalible, pero solo si la aplicas de verdad. El riesgo real no es clasificar mal un efecto obvio como Create charge; es no ver un efecto que se disfraza de otra cosa. Vale la pena entrenar el ojo para los efectos escondidos, porque son los que producen los duplicados que nadie esperaba.

Aquí hay cuatro disfraces comunes:

El efecto dentro de una lectura. Ya lo viste en el ejercicio: "verifica si el cliente existe; si no, créalo". Empieza como consulta y termina como creación. Cualquier operación que condicionalmente crea, cobra o envía es un efecto, aunque su parte visible sea una lectura.

El efecto que dispara otro workflow. Un nodo que "pone un mensaje en una cola" o "llama a otro workflow" parece inofensivo —solo está pasando datos— pero si ese otro workflow tiene efectos, entonces poner el mensaje es un efecto: repetirlo hace que el otro workflow corra dos veces y duplique. El efecto no está en el nodo que ves, sino en lo que ese nodo desata. Esto es central en el Módulo 5, cuando coordines varios workflows.

El efecto de un agente que usa herramientas. Un AI Agent que solo clasifica es casi una lectura, como vimos. Pero un AI Agent al que le diste herramientas —"puedes crear un registro", "puedes mandar un correo"— es un efecto en potencia, porque el agente puede decidir ejecutar una de esas herramientas. La peligrosidad de repetir un agente depende de qué herramientas puede tocar. El Módulo 2 le dedica una lección a la idempotencia de las acciones de un agente, justamente porque esconde efectos detrás de una fachada de "solo está pensando".

El efecto de escribir en un registro propio. Un nodo que "guarda una fila en nuestra base de datos" para llevar la cuenta es un efecto: repetirlo escribe dos filas. Es fácil de pasar por alto porque no toca un servicio externo famoso como una pasarela, pero cambia el estado igual. De hecho, en el Módulo 4 vas a usar este tipo de escritura como herramienta —el ledger que recuerda qué se procesó— y tendrás que hacerla idempotente a ella misma.

La lección de todo esto: no clasifiques por cómo se ve el nodo, clasifica por lo que deja en el mundo cuando termina. Un nodo puede llamarse "check", "route", "classify" o "log" y ser, por dentro, un efecto. La prueba de la repetición —aplicada al resultado real, no al nombre— es la que no se deja engañar.

La lectura como aliada, no solo como categoría inofensiva

Hasta aquí tratamos las lecturas como la categoría que puedes ignorar. Y es cierto que no necesitan protección. Pero vale la pena verlas también por su lado positivo, porque son una herramienta poderosa para el dueño del sistema, no solo un tipo de nodo sin riesgo.

Porque las lecturas son seguras de repetir, puedes usarlas con total libertad:

• Puedes reintentarlas sin miedo. Si Get customer falla por un parpadeo, actívale Retry On Fail sin pensarlo: reintentar una lectura nunca duplica. Es el único nodo de order-triage donde el reintento automático es gratis.
• Puedes consultar el estado antes de decidir. Una lectura te deja preguntar "¿este pedido ya se procesó?" sin cambiar nada. Es la base de muchas defensas —aunque, ojo, "leer para decidir si actúo" es justo donde acecha la trampa de verificar-y-luego-actuar de la lección 4: la lectura es segura, pero el hueco entre leerla y actuar sobre ella no—.
• Puedes verificar tu propio trabajo. Después de un efecto, una lectura te confirma que el estado quedó como esperabas, sin riesgo de alterarlo.

Piénsalo así: en un sistema, las lecturas son las ventanas y los efectos son las puertas. Por las ventanas puedes mirar todas las veces que quieras sin cambiar nada de adentro; las puertas dejan entrar y salir cosas, y hay que controlarlas. Un buen diseño usa muchas ventanas —consulta el estado libremente— y pocas puertas bien vigiladas. Cuando en el Módulo 4 construyas la memoria del sistema, vas a apoyarte constantemente en lecturas para preguntarle a esa memoria qué ya pasó.

Un matiz sobre borrar y actualizar

Dos verbos de efecto merecen una nota, porque su relación con la repetición es más rica de lo que parece, y te va a servir en el Módulo 2.

Borrar (DELETE) suele ser idempotente por naturaleza. "Borra el pedido ORD-2041": la primera vez lo borra; la segunda vez... ya no está, así que no pasa nada nuevo. El estado final —el pedido no existe— es el mismo con una ejecución o con tres. Por eso muchos borrados son seguros de repetir sin hacer nada especial. (Con una salvedad: si tu borrado también hace otra cosa, como registrar "se borró" o notificar, esa otra parte puede no ser idempotente.)

Actualizar a un valor fijo (PUT/PATCH que fija un estado) suele ser idempotente. "Pon el estado en pagado", "fija el precio en 100": repetir deja el mismo valor. Es la clase que vimos arriba. Pero cuidado con las actualizaciones relativas: "súmale 10 al saldo" NO es idempotente —dos ejecuciones suman 20—. La diferencia está en si la operación fija un valor (idempotente) o lo modifica en relación con el actual (no idempotente).

No necesitas memorizar esto ahora; el Módulo 2 lo desarrolla. Lo que quiero que veas es que "efecto" no es sinónimo de "peligroso de repetir". Algunos efectos ya son seguros por su forma (borrar, fijar un valor), y parte del arte de la idempotencia es convertir los efectos peligrosos (crear, cobrar, sumar) en la forma segura. La distinción lectura/efecto te dice dónde mirar; el análisis de repetición te dice cuánto peligro hay en cada efecto.

Si te sirve una escala mental, los efectos se ordenan así por qué tan seguros son de repetir, de más seguro a más peligroso:

Forma del efecto	Ejemplo	¿Seguro de repetir?
Fija un valor absoluto	"pon el estado en pagado"	Sí, idempotente por naturaleza
Borra por identidad	"borra el pedido ORD-2041"	Sí, casi siempre
Crea con clave de idempotencia	"crea el cobro con Idempotency-Key"	Sí, idempotencia construida
Crea sin clave	"crea un cobro"	No, duplica
Modifica en relativo	"súmale 10 al saldo"	No, acumula

Las dos primeras filas ya vienen seguras; la tercera es lo que aprendes a construir en el Módulo 2; las dos últimas son el peligro que esa construcción resuelve. Toda la idempotencia consiste en mover un efecto de las filas de abajo a las de arriba.

Errores comunes

Proteger las lecturas (práctico). Qué pasa: alguien, con buena intención de "hacer todo confiable", pone lógica de deduplicación o candados alrededor de un nodo que solo lee datos. El workflow queda más complejo y no ganó nada. Por qué pasa: el impulso de la mentalidad de dueño, mal calibrado, lleva a proteger todo. Cómo detectarlo: si tienes protección de idempotencia alrededor de un GET o de una consulta, es esfuerzo desperdiciado. Cómo corregirlo: aplica la prueba de la repetición antes de proteger. Si repetir la operación no cambia el mundo, es una lectura y no necesita nada. La confiabilidad es selectiva: protege efectos, ignora lecturas.

Clasificar por el verbo sin aplicar la prueba de la repetición (práctico). Qué pasa: alguien ve "actualizar" y lo marca como efecto peligroso, o ve "verificar" y lo marca como lectura, sin comprobar. A veces se equivoca: un "verifica y luego crea" esconde un efecto; un "actualiza a pagado" es un efecto seguro de repetir. Por qué pasa: el verbo es una buena señal pero no infalible. Cómo detectarlo: si clasificaste sin preguntarte "¿repetirlo cambia el mundo?", clasificaste por reflejo. Cómo corregirlo: el verbo es la primera pista; la prueba de la repetición es el veredicto. Cuando choquen, gana la prueba.

Confundir "cuesta" con "hace daño" (conceptual). Qué pasa: se trata al AI Agent como un efecto peligroso que hay que blindar contra duplicados con la misma urgencia que el cobro, porque "cuesta dinero". Por qué pasa: costo y daño se sienten parecidos —los dos son "malo si se repite"— pero son distintos. Cómo detectarlo: pregúntate si repetir la operación deja el estado incorrecto o solo gasta de más. Si solo gasta, es un problema de costo, no de seguridad al fallar. Cómo corregirlo: prioriza por daño al estado, no por costo. El costo se suele resolver de paso cuando deduplicas por otras razones, pero no es lo que define un efecto peligroso.

Creer que "efecto" significa "siempre peligroso de repetir" (conceptual). Qué pasa: se marca todo efecto como igualmente riesgoso, sin ver que borrar o fijar un valor ya son seguros de repetir. El resultado es proteger de más y no entender qué hace la idempotencia. Por qué pasa: "efecto = cambia el estado = peligroso" es una simplificación cómoda pero incompleta. Cómo detectarlo: si tratas "borra ORD-2041" y "crea un pedido" como igual de peligrosos, no distingues los efectos idempotentes por naturaleza de los que no lo son. Cómo corregirlo: dentro de los efectos, aplica la prueba de repetición para separar los ya-seguros (borrar, fijar) de los peligrosos (crear, cobrar, sumar). La idempotencia consiste, precisamente, en llevar los segundos a la forma de los primeros.

Ejercicios

Ejercicio 1 — Clasifica ocho operaciones. Para cada una, di si es lectura o efecto, y si es efecto, si repetirla es peligroso (duplica) o seguro (idempotente por naturaleza). Aplica la prueba de la repetición.

(a) GET /customers/CUST-118 — obtener la ficha del cliente. (b) POST /charges { amount: 2154 } — crear un cobro. (c) DELETE /orders/ORD-2041 — borrar el pedido. (d) PATCH /orders/ORD-2041 { status: "shipped" } — marcar como enviado. (e) POST /emails { to: customer, subject: "..." } — mandar un correo. (f) GET /orders?status=pending — listar pedidos pendientes. (g) POST /crm/notes { order_id: "...", text: "..." } — agregar una nota al pedido. (h) PATCH /inventory/CF-ARA-500 { stock: stock - 12 } — descontar 12 del inventario.

Ver solución

(a) Lectura. GET, consultar. Repetir no cambia nada.

(b) Efecto, peligroso. POST que crea un cobro. Cada repetición cobra de nuevo. El caso clásico a proteger.

(c) Efecto, seguro (idempotente por naturaleza). Borrar ORD-2041 dos veces deja el mismo estado: el pedido no existe. La segunda vez no hace nada nuevo.

(d) Efecto, seguro (idempotente por naturaleza). Fija el estado en "shipped". Repetir lo deja en "shipped". No duplica.

(e) Efecto, peligroso. Mandar un correo dos veces manda dos correos. Barato, pero un efecto real y duplicable.

(f) Lectura. GET, listar. Repetir no cambia nada.

(g) Efecto, peligroso. POST que agrega una nota. Cada repetición agrega otra nota. Añade, no fija: duplica.

(h) Efecto, peligroso. Es una actualización relativa —resta 12 del stock actual—. Dos ejecuciones restan 24. Aunque use PATCH, no es idempotente, porque modifica en relación con el valor actual en vez de fijar uno.

Por qué funciona: fíjate en (d) contra (h). Los dos son PATCH, los dos "actualizan", pero (d) fija un valor (idempotente) y (h) modifica relativo (no idempotente). El método HTTP no basta; la prueba de la repetición es la que decide. Esa es la razón por la que insistimos en preguntarse siempre "¿repetirlo cambia el mundo?".

Ejercicio 2 — Encuentra el efecto escondido. Este nodo se llama Check and register customer y hace esto: "consulta si el cliente existe en el CRM; si no existe, lo crea". ¿Es lectura o efecto? Justifica, y di por qué su nombre es engañoso.

Ver solución

Es un efecto, aunque su nombre empieza con "Check" (verificar), que suena a lectura. La clave está en la segunda mitad: "si no existe, lo crea". Esa creación es un efecto, y repetir la operación puede crear el cliente dos veces si dos ejecuciones consultan a la vez —antes de que ninguna alcance a crearlo— y las dos concluyen "no existe, lo creo". Es exactamente la trampa de "verificar y luego actuar" que viste en la lección 4.

El nombre es engañoso porque describe la operación por su primera acción visible (la consulta) y esconde la segunda (la creación). Un verbo de lectura al principio no convierte en lectura a una operación que termina creando algo.

Por qué funciona: aplicar la prueba de la repetición —"¿repetirlo puede dejar el mundo distinto?"— corta el engaño de inmediato: sí, puede dejar dos clientes donde debía haber uno. Cualquier operación que pueda terminar creando, cobrando, enviando o borrando es un efecto, sin importar cómo empiece su nombre. Y las operaciones "verifica y luego actúa" son efectos particularmente traicioneros, que el Módulo 2 trata con una lección propia.

Ejercicio 3 — Convierte un efecto peligroso en uno seguro. Toma la operación (g) del ejercicio 1 —"agrega una nota al pedido"— que es peligrosa de repetir porque cada ejecución añade otra nota. Sin conocer todavía las técnicas del Módulo 2, propón, con tus palabras, cómo la harías segura de repetir. Pista: piensa en qué información necesitarías para reconocer que "esta nota ya la agregué".

Ver solución

La idea central es darle a cada nota una identidad única y hacer que el sistema no agregue dos notas con la misma identidad. Por ejemplo: en lugar de "agrega una nota", la operación sería "agrega la nota identificada por note_id: nt_evt_8f2a91c4", derivando ese identificador del event_id del pedido. La primera ejecución crea la nota con ese id; la segunda ejecución, al intentar crear una nota con el mismo id, es reconocida como repetida y no agrega una segunda.

Otra forma de decirlo: conviertes "añadir una nota nueva" (que duplica) en "asegurar que existe la nota con este id" (que fija, y por tanto es idempotente). El efecto sigue ocurriendo —la nota se agrega— pero repetirlo deja de duplicar, porque el id ancla la operación a una nota específica.

Por qué funciona: acabas de reinventar, con tus palabras, la idea de la clave de idempotencia, que es el corazón del Módulo 2. Fíjate en el patrón general: los efectos peligrosos se vuelven seguros dándoles una identidad estable —una clave— que permite reconocer la repetición. No importa cuántas veces llegue el evento; la clave garantiza que el efecto ocurra una sola vez. Eso es idempotencia construida, y ya la intuiste tú solo.

Resumen y siguiente paso

En esta lección instalaste la distinción que sostiene toda la guía. Una lectura toma información sin cambiar el estado del sistema —consultar, obtener, listar, verificar— y repetirla no tiene consecuencias: es el termómetro que puedes mirar cien veces sin calentar la habitación. Un efecto cambia el estado —crear, cobrar, enviar, borrar, actualizar— y repetirlo tiene consecuencias: es la estufa que, encendida dos veces, calienta de más. Solo los efectos pueden dejar el sistema peor, así que solo ellos necesitan protección. Esto vuelve la confiabilidad selectiva: en order-triage, de seis nodos, solo tres son efectos, y solo esos tres reclaman tu atención.

Para clasificar tienes dos señales: el verbo de la operación (get/list son lectura; create/charge/send son efecto) y, sobre todo, la prueba de la repetición —"¿ejecutarlo dos veces deja el mundo distinto de ejecutarlo una?"— que decide incluso cuando el verbo engaña. Viste que no todos los efectos son igual de peligrosos: borrar y fijar un valor ya son idempotentes por naturaleza, mientras que crear, cobrar y sumar duplican. Y llegaste a la definición central: una operación es idempotente si ejecutarla dos veces deja el mismo estado que ejecutarla una, y —la idea que abre el Módulo 2— la idempotencia no es solo una propiedad que se tiene, es algo que se construye, transformando un efecto peligroso en uno seguro mediante una clave que ancla el efecto a una identidad única.

Antes de avanzar deberías poder: clasificar cualquier nodo como lectura o efecto con la prueba de la repetición; explicar por qué proteger una lectura es esfuerzo desperdiciado; distinguir un efecto peligroso de repetir (crear, cobrar) de uno idempotente por naturaleza (borrar, fijar un valor); y definir idempotencia con tus palabras.

Ya tienes todas las piezas del vocabulario: constructor vs dueño, confiable, el modelo de ejecución, "al menos una vez", los cuatro modos de falla, y ahora lecturas vs efectos. La lección 8 las junta en la práctica que es la capacidad de salida del módulo: vas a auditar un workflow frágil de principio a fin —clasificar cada nodo, listar sus modos de falla, predecir qué pasa si se dispara dos veces— y entregar una tabla de riesgo por nodo. Es el examen práctico de todo lo que aprendiste, y el ensayo de lo que harás con cada workflow real que te toque.

Recursos

• HTTP Request node — n8n Docs — el nodo con el que harás casi todos los efectos externos de la guía; su parámetro de método (GET, POST, PUT, PATCH, DELETE) es la primera pista de si una operación es lectura o efecto.
• HTTP request methods — referencia MDN — la referencia estándar de los métodos HTTP, incluyendo cuáles se consideran "seguros" (safe) e idempotentes por definición del protocolo. Útil para afinar la intuición lectura/efecto.
• Idempotence — referencia general — la definición formal del concepto que da nombre a la guía; confirma que "dos veces igual que una" es la idea central, tal como la usamos aquí.
• Data structure — n8n Docs — cómo fluyen los datos entre nodos; recordar que los items son pasajeros (no son el estado) ayuda a distinguir lo que cambia el estado de lo que solo lo transporta.