¿Qué es la idempotencia?

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.

Ventajas clave de los sistemas idempotentes

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.

Métodos HTTP idempotentes y no idempotentes

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.

Métodos idempotentes (GET, PUT, DELETE)

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.

  • GET: este método recupera datos. Como no cambia nada en el servidor, puedes llamarlo un millón de veces y el recurso sigue siendo el mismo.
  • PUT: este método sustituye un recurso por completo. Si actualizas el correo de un usuario a "usuario@example.com" tres veces, el estado final sigue siendo que el correo es "usuario@example.com".
  • DELETE: elimina un recurso. Si eliminas el pedido n.º 123 y luego intentas eliminarlo de nuevo, el pedido seguirá eliminado. El resultado (el pedido se ha eliminado) sigue siendo el mismo.

Métodos no idempotentes (POST, PATCH)

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.

  • POST: los desarrolladores usan POST para crear recursos nuevos. Sin la lógica de idempotencia, enviar la misma solicitud POST dos veces (por ejemplo, "Enviar pago") normalmente daría lugar a dos registros independientes y a dos cargos al cliente.
  • PATCH; este método aplica actualizaciones parciales. Aunque se puede hacer idempotente, no suele serlo de forma predeterminada porque repetir un cambio relativo (como "añadir 5 al saldo") daría como resultado un valor final diferente cada vez que se llama.

Cómo implementar una API idempotente

  1. Generar una clave única: el cliente crea una cadena única (como un UUID) y la incluye en un encabezado HTTP personalizado.
  2. Interceptar y validar: el servidor comprueba un almacén de datos de alta velocidad como Memorystore para ver si esa clave se ha procesado recientemente.
  3. Gestionar el estado: si la clave es nueva, procesa la solicitud y guarda el resultado. Si es un duplicado, devuelve el resultado almacenado inmediatamente sin volver a ejecutar la lógica empresarial.

Casos prácticos habituales de la idempotencia

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.

  • Acción necesaria por parte del desarrollador: debes implementar una clave de idempotencia (normalmente un UUID) en tu solicitud a la API para que el segundo clic se reconozca como un reintento y se proteja la cuenta bancaria del cliente.

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.

  • Gestionado por ti: la propia herramienta de IaC gestiona la idempotencia; como desarrollador, no tienes que escribir lógica adicional para evitar recursos duplicados.

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.

  • Acción del desarrollador necesaria: al crear el backend, debes implementar la lógica para interceptar estas claves, comprobar si ha habido intentos anteriores y devolver la respuesta almacenada en caché.

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".

  • Se gestiona automáticamente: esta lógica se gestiona de forma nativa en el motor de base de datos, lo que garantiza que los registros converjan al estado correcto independientemente de cuántas veces se ejecute la secuencia de comandos.

Soluciona los retos empresariales que se te presenten con Google Cloud

Los nuevos clientes reciben 300 USD en crédito sin coste para invertirlos en Google Cloud.
Habla con un especialista del equipo de ventas de Google Cloud sobre tus necesidades específicas con más detalle.

Crear microservicios fiables en Google Cloud

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.

  • Cloud Run: cuando uses Cloud Run para procesar eventos de Pub/Sub, recuerda que Pub/Sub puede enviar mensajes más de una vez de forma predeterminada. Escribir código idempotente en tus servicios de Cloud Run es un requisito para asegurar que tus agentes de IA o tus flujos de procesamiento de datos no procesen el mismo evento dos veces.
  • Nota sobre Pub/Sub: aunque la entrega predeterminada se basa en push, la entrega exacta una sola vez está disponible para las suscripciones basadas en pull. Es útil conocer estos dos tipos para elegir el nivel de complejidad adecuado para tu servicio.

¿Todo listo para empezar a compilar?

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

Google Cloud