Qu'est-ce que l'idempotence, et comment les idempotency keys rendent-elles les retries sûrs ?

Question

IT Interview Practice · Accepted Answer

L'**idempotence (idempotency)** signifie qu'effectuer une opération **plusieurs fois a le même effet que l'effectuer une fois**. Cela compte parce que les réseaux ne sont pas fiables : quand un client envoie une requête et que la réponse n'arrive jamais, il ne peut pas savoir si le serveur l'a traitée. S'il réessaie, une opération non idempotente pourrait s'exécuter deux fois.

## Le problème

```text
Client ──POST /payments {$100}──▶ Server   (débite 100 $ ✓)
Client ◀────────X (timeout)────── Server   (réponse perdue)
Client ──POST /payments {$100}──▶ Server   (débite 100 $ À NOUVEAU ✗ → 200 $ !)
```

`GET`, `PUT` et `DELETE` sont naturellement idempotents, donc les réessayer est sûr. `POST` ne l'est **pas** — c'est exactement de là que viennent les débits en double et les orders en double.

## La solution : les idempotency keys

Le client génère une **clé unique** (généralement un UUID) pour l'opération logique et l'envoie dans un header. Le serveur stocke la clé avec le résultat ; si la même clé arrive à nouveau, il retourne le résultat **stocké** au lieu de réexécuter.

```http
POST /payments HTTP/1.1
Idempotency-Key: 5f2b8c1e-3a4d-4e6f-9c0b-1a2b3c4d5e6f
Content-Type: application/json

{ "amount": 100, "currency": "usd" }
```

```text
Logique du serveur à la réception d'une requête avec une Idempotency-Key :
  1. Chercher la clé dans un store (p. ex. Redis/DB).
  2. Si trouvée → retourner la réponse sauvegardée (pas de nouveau débit).  ← le cas du retry
  3. Sinon → traiter, sauvegarder (clé → réponse), puis retourner.
  (Enveloppez l'étape 3 dans une transaction / un lock pour que des retries concurrents ne s'exécutent pas deux fois.)
```

La **même clé** au retry produit le même `200` et le même paiement — le client est débité une seule fois. C'est exactement ainsi que fonctionne l'API de Stripe.

## Pourquoi c'est important

Cette question sépare les ingénieurs qui conçoivent pour le happy path de ceux qui conçoivent pour l'**échec**, ce qui est l'essence de la fiabilité en production. Les systèmes distribués garantissent que les timeouts et les pannes partielles *se produiront*, donc tout endpoint avec effets de bord — paiements, orders, envoi d'argent — a besoin d'une stratégie de retry, et « réessaie simplement » est dangereux pour `POST`. Le recruteur veut entendre l'idée en deux parties : d'abord, que l'idempotence est une propriété que vous pouvez *concevoir* (rendre `PUT`/`DELETE` naturellement sûrs, et donner à `POST` une **idempotency key** quand il ne peut pas l'être), et ensuite, le détail subtil de concurrence — deux retries arrivant en même temps ne doivent pas s'exécuter tous les deux, donc la vérification de la clé et l'écriture ont besoin d'un lock ou d'une contrainte d'unicité. Réussir cela fait la différence entre débiter un client une fois et le débiter deux fois, c'est pourquoi toute API de paiement et de commerce sérieuse l'implémente.

Le problème

La solution : les idempotency keys

Pourquoi c'est important

Questions connexes