Was ist Idempotenz und wie machen Idempotency Keys Retries sicher?

Question

IT Interview Practice · Accepted Answer

**Idempotenz** bedeutet, dass eine Operation **mehrmals auszuführen denselben Effekt hat wie einmal**. Es ist wichtig, weil Netzwerke unzuverlässig sind: wenn ein Client einen Request sendet und die Response nie ankommt, kann er nicht wissen, ob der Server ihn verarbeitet hat. Wenn er wiederholt, könnte eine nicht-idempotente Operation zweimal laufen.

## Das Problem

```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` und `DELETE` sind natürlicherweise idempotent, sodass ihr Wiederholen sicher ist. `POST` ist es **nicht** — genau hier entstehen doppelte Abbuchungen und doppelte Orders.

## Die Lösung: Idempotency Keys

Der Client generiert einen **eindeutigen Key** (meist eine UUID) für die logische Operation und sendet ihn in einem Header. Der Server speichert den Key mit dem Ergebnis; wenn derselbe Key erneut ankommt, gibt er das **gespeicherte** Ergebnis zurück, statt erneut auszuführen.

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

Der **gleiche Key** beim Retry liefert dasselbe `200` und dieselbe Zahlung — der Kunde wird einmal belastet. Genau so funktioniert die API von Stripe.

## Warum es wichtig ist

Diese Frage trennt Ingenieure, die für den Happy Path entwerfen, von jenen, die für das **Versagen** entwerfen, worum es bei Produktionszuverlässigkeit geht. Verteilte Systeme garantieren, dass Timeouts und partielle Ausfälle *passieren werden*, sodass jeder Endpoint mit Seiteneffekten — Zahlungen, Orders, Geld senden — eine Retry-Story braucht, und "einfach wiederholen" ist bei `POST` gefährlich. Der Interviewer will die zweiteilige Einsicht hören: erstens, dass Idempotenz eine Eigenschaft ist, die man *hineindesignen* kann (`PUT`/`DELETE` natürlich sicher machen und `POST` einen **Idempotency Key** geben, wenn es das nicht sein kann), und zweitens das subtile Concurrency-Detail — zwei gleichzeitig ankommende Retries dürfen nicht beide ausführen, sodass die Key-Prüfung und der Write ein Lock oder eine Unique Constraint brauchen. Das richtig zu machen ist der Unterschied zwischen einer einmaligen und einer doppelten Belastung des Kunden, weshalb jede ernsthafte Zahlungs- und Commerce-API es implementiert.

Das Problem

Die Lösung: Idempotency Keys

Warum es wichtig ist

Ähnliche Fragen