En informática, la idempotencia es una propiedad de una operación que hace que aplicarla varias veces tenga el mismo efecto final que aplicarla una sola vez. Si envías la misma solicitud a un servidor cinco veces, un sistema idempotente se asegura de que el resultado en el servidor no cambie después del primer intento satisfactorio.
Además de garantizar el mismo resultado, una característica clave de las operaciones idempotentes es que no producen efectos secundarios con llamadas adicionales. Este es un requisito fundamental para crear sistemas distribuidos resilientes en los que las interrupciones intermitentes de la red o los tiempos de espera agotados pueden hacer que un cliente envíe el mismo mensaje más de una vez.
Analogía: piensa en el botón de subir de un ascensor. Si lo pulsas una vez, el ascensor sube a tu planta. Si lo pulsas diez veces más mientras esperas, el resultado es el mismo: solo un ascensor subirá a tu planta. Si pulsas el botón varias veces, no aparecerán diez ascensores. En cambio, añadir un artículo a un carrito de la compra digital no suele ser idempotente. Si haces clic en el botón "Añadir al carrito" cinco veces, probablemente acabarás con cinco unidades de ese artículo en tu cesta.
Vuelve a intentar las solicitudes de forma segura tras un tiempo de espera agotado o una caída de la conexión sin miedo a duplicar acciones (como cobrar dos veces en una tarjeta de crédito).
Los usuarios no necesitan un seguimiento de estado complejo para saber si una solicitud anterior se ha completado correctamente; pueden simplemente "volver a intentarlo hasta que funcione".
Los sistemas distribuidos pueden recuperarse de los fallos reproduciendo los registros o volviendo a enviar los mensajes perdidos sin dañar los datos.
El estándar REST define cómo deben comportarse los diferentes tipos de solicitudes web. Algunos métodos HTTP son "seguros" o idempotentes por diseño, lo que significa que la especificación espera que se comporten de forma predecible incluso cuando se repiten. Otras están diseñadas para crear datos nuevos y requieren más atención para que se puedan reintentar de forma segura.
Según el RFC 9110, varios métodos estándar son inherentemente idempotentes. Al repetir estas acciones, el estado del servidor no debería cambiar más allá de la solicitud inicial.
Algunos métodos no son idempotentes porque su función principal es cambiar los datos de forma que se cree algo nuevo o se modifique una parte de un registro existente.
La idempotencia suele ser necesaria en los sistemas que creamos. En algunos casos, se gestiona por nosotros. En otros casos, los desarrolladores debemos tomar medidas para que esto ocurra.
El ejemplo más famoso es el problema del "doble cargo". Si el navegador de un usuario se bloquea mientras está pagando un vuelo, puede que haga clic en "Pagar" de nuevo. Una API de pagos que usa una clave de idempotencia garantiza que el segundo clic se reconozca como un reintento. De esta forma, se protege la cuenta bancaria del cliente y se reduce el coste operativo de gestionar los reembolsos de las transacciones duplicadas.
Herramientas como Terraform y Ansible se basan en la idempotencia. Cuando ejecutas una secuencia de comandos para "crear un segmento de almacenamiento de 10 GB", la herramienta comprueba el estado actual de tu nube.
Las APIs web modernas suelen implementar el encabezado Idempotency-Key (ahora un borrador estandarizado de IETF) para permitir a los desarrolladores crear integraciones más sólidas.
Una operación de "upsert" (actualización o inserción) es una operación de base de datos idempotente clásica. En lugar de una simple inserción, una operación de upsert dice: "Si este registro existe, actualízalo; si no, créalo".
Google Cloud proporciona varias herramientas que facilitan la implementación de estos patrones a los desarrolladores. Al basarse en una plataforma gestionada, se reduce la cantidad de código repetitivo que tienes que escribir para mantener tus datos a salvo.


Descubre cómo desplegar servicios resilientes e idempotentes en Cloud Run hoy mismo.