Hvad er idempotency, og hvordan gør idempotency keys retries sikre?

Question

IT Interview Practice · Accepted Answer

**Idempotency** betyder, at det at udføre en operation **flere gange har samme effekt som at udføre den én gang**. Det betyder noget, fordi netværk er upålidelige: når en client sender en request, og responset aldrig ankommer, kan den ikke vide, om serveren behandlede den. Hvis den prøver igen, kan en ikke-idempotent operation køre to gange.

## Problemet

```text
Client ──POST /payments {$100}──▶ Server   (trækker $100 ✓)
Client ◀────────X (timeout)────── Server   (response tabt)
Client ──POST /payments {$100}──▶ Server   (trækker $100 IGEN ✗ → $200!)
```

`GET`, `PUT` og `DELETE` er naturligt idempotente, så det er sikkert at prøve dem igen. `POST` er **ikke** — det er præcis her, dobbelttrækninger og dubletordrer kommer fra.

## Løsningen: idempotency keys

Clienten genererer en **unik key** (som regel et UUID) for den logiske operation og sender den i en header. Serveren gemmer key'en sammen med resultatet; hvis den samme key ankommer igen, returnerer den det **gemte** resultat i stedet for at eksekvere igen.

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

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

```text
Server-logik ved modtagelse af en request med en Idempotency-Key:
  1. Slå key'en op i et store (fx Redis/DB).
  2. Hvis fundet → returnér det gemte response (ingen ny trækning).   ← retry-tilfældet
  3. Hvis ikke  → behandl, gem (key → response), returnér så.
  (Pak 3 ind i en transaktion / lock, så samtidige retries ikke dobbelt-eksekverer.)
```

**Den samme key** ved retry giver det samme `200` og den samme betaling — kunden trækkes én gang. Det er præcis sådan, Stripes API fungerer.

## Hvorfor det betyder noget

Dette spørgsmål adskiller ingeniører, der designer til the happy path, fra dem, der designer til **fejl**, hvilket er, hvad produktionspålidelighed handler om. Distribuerede systemer garanterer, at timeouts og delvise fejl *vil* ske, så ethvert endpoint med side effects — betalinger, ordrer, pengeoverførsler — har brug for en retry-strategi, og "bare prøv igen" er farligt for `POST`. Intervieweren vil høre den todelte indsigt: for det første, at idempotency er en egenskab, du kan *designe ind* (ved at gøre `PUT`/`DELETE` naturligt sikre og give `POST` en **idempotency key**, når den ikke selv kan være det), og for det andet den subtile samtidighedsdetalje — to retries, der ankommer samtidigt, må ikke begge eksekvere, så key-tjekket og skrivningen har brug for en lock eller unique constraint. At ramme dette rigtigt er forskellen mellem at trække en kunde én gang og at trække dem to gange, hvilket er grunden til, at enhver seriøs betalings- og handels-API implementerer det.

Problemet

Løsningen: idempotency keys

Hvorfor det betyder noget

Relaterede spørgsmål