Vad är idempotency, och hur gör idempotency keys retries säkra?

Question

IT Interview Practice · Accepted Answer

**Idempotency** betyder att utföra en operation **flera gånger har samma effekt som att utföra den en gång**. Det spelar roll eftersom nätverk är opålitliga: när en client skickar en request och responsen aldrig kommer fram kan den inte avgöra om servern bearbetade den. Om den försöker igen kan en icke-idempotent operation köras två gånger.

## Problemet

```text
Client ──POST /payments {$100}──▶ Server   (debiterar $100 ✓)
Client ◀────────X (timeout)────── Server   (response förlorad)
Client ──POST /payments {$100}──▶ Server   (debiterar $100 IGEN ✗ → $200!)
```

`GET`, `PUT` och `DELETE` är naturligt idempotent, så att försöka igen med dem är säkert. `POST` är **inte** — det är precis här duplicerade debiteringar och duplicerade orders kommer från.

## Lösningen: idempotency keys

Client:en genererar en **unik nyckel** (oftast en UUID) för den logiska operationen och skickar den i en header. Servern lagrar nyckeln med resultatet; om samma nyckel kommer igen returnerar den det **lagrade** resultatet i stället för att köra om.

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

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

```text
Server-logik vid mottagande av en request med en Idempotency-Key:
  1. Slå upp nyckeln i en store (t.ex. Redis/DB).
  2. Om hittad → returnera den sparade responsen (ingen ny debitering).  ← retry-fallet
  3. Om inte  → bearbeta, spara (key → response), returnera sedan.
  (Omslut 3 i en transaction / lock så att samtidiga retries inte kör dubbelt.)
```

**Samma nyckel** vid retry ger samma `200` och samma payment — kunden debiteras en gång. Det är precis så Stripes API fungerar.

## Varför det är viktigt

Denna fråga skiljer ingenjörer som designar för the happy path från dem som designar för **misslyckande**, vilket är vad produktionstillförlitlighet handlar om. Distribuerade system garanterar att timeouts och partiella fel *kommer* att hända, så varje endpoint med sidoeffekter — payments, orders, att skicka pengar — behöver en retry-strategi, och "bara försök igen" är farligt för `POST`. Intervjuaren vill höra den tvådelade insikten: först, att idempotency är en egenskap du kan *designa in* (göra `PUT`/`DELETE` naturligt säkra, och ge `POST` en **idempotency key** när det inte kan vara det), och för det andra, den subtila samtidighetsdetaljen — två retries som kommer samtidigt får inte båda köra, så nyckelkontrollen och skrivningen behöver ett lock eller unique constraint. Att få detta rätt är skillnaden mellan att debitera en kund en gång och att debitera dem två gånger, vilket är varför varje seriöst payments- och commerce-API implementerar det.

Problemet

Lösningen: idempotency keys

Varför det är viktigt

Relaterade frågor