Wat is idempotency, en hoe maken idempotency keys retries veilig?

Question

IT Interview Practice · Accepted Answer

**Idempotency** betekent dat een operatie **meerdere keren uitvoeren hetzelfde effect heeft als hem één keer uitvoeren**. Het is belangrijk omdat netwerken onbetrouwbaar zijn: wanneer een client een request stuurt en de response nooit aankomt, kan hij niet weten of de server hem heeft verwerkt. Als hij opnieuw probeert, kan een niet-idempotente operatie twee keer draaien.

## Het probleem

```text
Client ──POST /payments {$100}──▶ Server   (charges $100 ✓)
Client ◀────────X (timeout)────── Server   (response lost)
Client ──POST /payments {$100}──▶ Server   (charges $100 AGAIN ✗ → $200!)
```

`GET`, `PUT` en `DELETE` zijn van nature idempotent, dus ze opnieuw proberen is veilig. `POST` is dat **niet** — hier komen dubbele afschrijvingen en dubbele orders precies vandaan.

## De oplossing: idempotency keys

De client genereert een **unieke key** (meestal een UUID) voor de logische operatie en stuurt hem in een header. De server bewaart de key met het resultaat; als dezelfde key opnieuw binnenkomt, retourneert hij het **opgeslagen** resultaat in plaats van opnieuw uit te voeren.

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

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

```text
Server logic on receiving a request with an Idempotency-Key:
  1. Look up the key in a store (e.g. Redis/DB).
  2. If found → return the saved response (no re-charge).      ← the retry case
  3. If not  → process, save (key → response), then return.
  (Wrap 3 in a transaction / lock so concurrent retries don't double-execute.)
```

**Dezelfde key** bij een retry levert dezelfde `200` en dezelfde betaling op — de klant wordt één keer belast. Zo werkt de API van Stripe precies.

## Waarom het belangrijk is

Deze vraag scheidt engineers die voor het happy path ontwerpen van wie voor **falen** ontwerpt, en daar draait productiebetrouwbaarheid om. Gedistribueerde systemen garanderen dat timeouts en gedeeltelijke fouten *zullen* gebeuren, dus elk endpoint met side effects — betalingen, orders, geld versturen — heeft een retry-verhaal nodig, en "gewoon opnieuw proberen" is gevaarlijk voor `POST`. De interviewer wil het tweeledige inzicht horen: ten eerste dat idempotency een eigenschap is die je *kunt inontwerpen* (`PUT`/`DELETE` van nature veilig maken, en `POST` een **idempotency key** geven wanneer het dat niet kan), en ten tweede het subtiele concurrency-detail — twee retries die tegelijk aankomen mogen niet allebei uitvoeren, dus de key-check en de write hebben een lock of unique constraint nodig. Dit goed krijgen is het verschil tussen een klant één keer belasten en twee keer, en daarom implementeert elke serieuze betaal- en commerce-API het.

Het probleem

De oplossing: idempotency keys

Waarom het belangrijk is

Gerelateerde vragen