
Hace unos días estaba intentando hacer un pago desde el navegador de mi teléfono, sin embargo, la conexión en donde yo estaba no era limitada, y el sitio web cargaba extremadamente lento.

A pesar de la demora, necesitaba hacer una transacción tan pronto como fuera posible; cuando ya había rellenado el checkout para completar el pago, oprimí el botón de ‘Pagar’, pero la conexión era tan deficiente que la aplicación no respondía en lo absoluto.

Entonces volví a presionar el botón, una y otra vez.



> 💡 Idempotencia significa que una operación produce el mismo resultado, sin importar cuántas veces se ejecute.

**Afortunadamente, este sistema era idempotente.** Porque de no haber sido por esto, lo más seguro es que se me hubieran cobrado las más de 20 veces que presioné el botón 😅.

## ¿Qué es la idempotencia?

La ingeniería establece que las redes no son siempre confiables, y eso aplica tanto para solicitudes como para respuestas. Es decir, nunca sabes si el mensaje terminará de recibirse o entregarse.

El verdadero peligro, es que la respuesta no se entregue. Este diagrama lo explica mejor:

![Descripción de la imagen](/blog/01-hello-world/idempotency_scenery.png)

Lo que sucede es que:

- Si el servidor **no recibe la solicitud**, es seguro volverla a enviar, pues el estado no se ha alterado.

- Pero **si el servidor recibe la solicitud**, este la procesará y (seguramente) alterará el estado de la aplicación. Pero eso el cliente nunca lo sabrá, por lo que es realmente arriesgado volverlo a intentar.

Evitar esa zona de peligro es crucial para evitar problemas relacionados con la experiencia del usuario.

Bien, entonces podríamos persistir el estado de la transacción, por si algo llega a fallar, saber si es seguro reintentarla.

Eso sí, es mejor hacerlo en memoria, pues las consultas al disco son más lentas y costosas. Así que optaremos por una caché en vez de una base de datos tradicional.

## ¿Cómo implementar la idempotencia?

### 1. Añadir un identificador a cada solicitud

Podemos llamarlo requestId (o en su forma abreviada, `rid`).

Para generarlo, es una buena idea combinar la marca de tiempo (_timestamp_) con algún otro dato que lo haga único. Por ejemplo, el ID del usuario o un número aleatorio.

```javascript
const crypto = require('crypto');

function generateRid(userId) {
  const timestamp = Date.now().toString();
  const base = `${userId}:${timestamp}`;

  const hash = crypto.createHash('sha256').update(base).digest('hex');
  return hash;
}
```

Al recibir una solicitud, lo primero que deberíamos hacer es almacenar el `rid` + un estado inicial como 'processing' en la caché.

Para eso Redis viene genial.

### 2. Al recibir la solicitud, comprobar la caché

Siempre, al recibir cualquier solicitud, hacer una verificación previsa de la caché antes que el servidor la reciba.

Aquí pueden suceder dos cosas:

- Que el `rid` ya exista en caché, lo que significaría

3. Si no existe en caché

    a. Cachearla: almacena el rid en caché con un estado asociado.

    b. Comprueba si existe en la base de datos: es una buena idea que registres los rid en la base de datos tal como lo haces en Redis, y verifiques si la operación existe en la BD.

    Esto se debe a que el caché suele tener un TTL (Time-To-Live). Aunque es raro, una solicitud podría reintentarse luego de que el caché haya vencido, y por lo tanto, volverse a ejecutar. La mejor forma de prevenir esto, es corroborando también en la base de datos.

    c. Si existe en la BD, actualiza el caché y devuelve la respuesta.

    d. Si no existe en la DB, realiza el proceso original y devuelve la respuesta



Si existe en caché





Consulta el estado del rid : de ser done (o como tu lo hayas llamado), retorna la respuesta que corresponda. De lo contrario retorna un error que indique que está en proceso.

lejoww

Hola, soy Alejo

Qué hago

Contenido y redes

Contenido técnico que la gente entiende

Web, automatización e IA

¿Tu marca necesita contenido que funcione?