Czym jest idempotentność i jak idempotency keys czynią ponawianie bezpiecznym?

Question

IT Interview Practice · Accepted Answer

**Idempotentność (idempotency)** oznacza, że wykonanie operacji **wiele razy ma ten sam efekt co wykonanie jej raz**. Ma znaczenie, bo sieci są zawodne: gdy klient wysyła żądanie, a odpowiedź nigdy nie dociera, nie może stwierdzić, czy serwer je przetworzył. Jeśli ponowi, operacja nieidempotentna może wykonać się dwa razy.

## 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` i `DELETE` są naturalnie idempotentne, więc ich ponawianie jest bezpieczne. `POST` **nie** jest — dokładnie stąd biorą się zdublowane obciążenia i zdublowane zamówienia.

## Rozwiązanie: idempotency keys

Klient generuje **unikalny klucz** (zwykle UUID) dla operacji logicznej i wysyła go w nagłówku. Serwer przechowuje klucz wraz z wynikiem; jeśli ten sam klucz nadejdzie ponownie, zwraca **zapisany** wynik zamiast wykonywać operację od nowa.

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

**Ten sam klucz** przy ponowieniu daje ten sam `200` i tę samą płatność — klient jest obciążony raz. Dokładnie tak działa API Stripe.

## Dlaczego to ważne

To pytanie oddziela inżynierów, którzy projektują pod happy path, od tych, którzy projektują pod **awarię**, o co właśnie chodzi w niezawodności produkcyjnej. Systemy rozproszone gwarantują, że timeouty i częściowe awarie *się zdarzą*, więc każdy endpoint z efektami ubocznymi — płatności, zamówienia, wysyłanie pieniędzy — potrzebuje strategii ponawiania, a „po prostu ponów" jest niebezpieczne dla `POST`. Rozmówca chce usłyszeć dwuczęściowe spostrzeżenie: po pierwsze, że idempotentność to właściwość, którą można *zaprojektować* (czyniąc `PUT`/`DELETE` naturalnie bezpiecznymi i dając `POST` **idempotency key**, gdy sam bezpieczny być nie może), a po drugie, subtelny szczegół współbieżności — dwa ponowienia docierające naraz nie mogą oba się wykonać, więc sprawdzenie klucza i zapis potrzebują locka lub ograniczenia unikalności (unique constraint). Zrobienie tego dobrze to różnica między obciążeniem klienta raz a obciążeniem dwa razy, dlatego każde poważne API płatnicze i handlowe to implementuje.

Problem

Rozwiązanie: idempotency keys

Dlaczego to ważne

Powiązane pytania