Hva er idempotens, og hvordan gjør idempotency-nøkler retries trygge?

Question

IT Interview Practice · Accepted Answer

**Idempotens** betyr at det å utføre en operasjon **flere ganger har samme effekt som å utføre den én gang**. Det betyr noe fordi nettverk er upålitelige: når en klient sender en request og responsen aldri kommer fram, kan den ikke vite om serveren behandlet den. Hvis den prøver på nytt, kan en ikke-idempotent operasjon kjøre to ganger.

## Problemet

```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` og `DELETE` er naturlig idempotente, så det er trygt å prøve dem på nytt. `POST` er **ikke** det — det er nettopp her dobbelttrekk og dobbeltordrer kommer fra.

## Løsningen: idempotency-nøkler

Klienten genererer en **unik nøkkel** (vanligvis en UUID) for den logiske operasjonen og sender den i en header. Serveren lagrer nøkkelen sammen med resultatet; hvis samme nøkkel kommer igjen, returnerer den det **lagrede** resultatet i stedet for å kjøre på nytt.

```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.)
```

**Samme nøkkel** ved retry gir samme `200` og samme betaling — kunden trekkes én gang. Dette er nøyaktig hvordan Stripe sitt API fungerer.

## Hvorfor det er viktig

Dette spørsmålet skiller ingeniører som designer for happy path fra de som designer for **feil**, som er det driftspålitelighet handler om. Distribuerte systemer garanterer at timeouts og delvise feil *vil* skje, så ethvert endepunkt med sideeffekter — betalinger, ordrer, pengeoverføringer — trenger en retry-strategi, og "bare prøv på nytt" er farlig for `POST`. Intervjueren vil høre den todelte innsikten: for det første at idempotens er en egenskap du kan *designe inn* (gjøre `PUT`/`DELETE` naturlig trygge, og gi `POST` en **idempotency-nøkkel** når den ikke kan være det), og for det andre det subtile samtidighetsdetaljet — to retries som kommer samtidig må ikke begge kjøre, så nøkkelsjekken og skrivingen trenger en lock eller unique constraint. Å få dette riktig er forskjellen mellom å trekke en kunde én gang og å trekke to ganger, som er grunnen til at hvert seriøst betalings- og handels-API implementerer det.

Problemet

Løsningen: idempotency-nøkler

Hvorfor det er viktig

Relaterte spørsmål