Mi az idempotencia, és hogyan teszik az idempotency key-ek biztonságossá az újrapróbálásokat?

Question

IT Interview Practice · Accepted Answer

Az **idempotencia** azt jelenti, hogy egy művelet **többszöri végrehajtása ugyanolyan hatással jár, mint az egyszeri**. Azért fontos, mert a hálózatok megbízhatatlanok: amikor egy kliens elküld egy kérést, és a válasz sosem érkezik meg, nem tudja megállapítani, hogy a server feldolgozta-e. Ha újrapróbálja, egy nem-idempotens művelet kétszer futhat le.

## A probléma

```text
Client ──POST /payments {$100}──▶ Server   (charges $100 ✓)
Client ◀────────X (timeout)────── Server   (response lost)
Client ──POST /payments {$100}──▶ Server   (charges $100 AGAIN ✗ → $200!)
```

A `GET`, `PUT` és `DELETE` természetüknél fogva idempotensek, így az újrapróbálásuk biztonságos. A `POST` **nem** — pontosan innen erednek a dupla terhelések és a dupla orderek.

## A megoldás: idempotency key-ek

A kliens egy **egyedi kulcsot** (általában egy UUID-t) generál a logikai művelethez, és egy headerben küldi el. A server a kulcsot az eredménnyel együtt tárolja; ha ugyanaz a kulcs újra megérkezik, a **tárolt** eredményt adja vissza az újbóli végrehajtás helyett.

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

**Ugyanaz a kulcs** újrapróbáláskor ugyanazt a `200`-at és ugyanazt a paymentet eredményezi — az ügyfél egyszer kerül megterhelésre. Pontosan így működik a Stripe API-ja.

## Miért fontos

Ez a kérdés elválasztja azokat a mérnököket, akik a happy path-ra terveznek, azoktól, akik a **hibára** terveznek, ami az éles megbízhatóság lényege. Az elosztott rendszerek garantálják, hogy timeoutok és részleges hibák *fognak* történni, így bármely mellékhatással bíró endpointnak — fizetések, orderek, pénzküldés — szüksége van retry-stratégiára, és a "csak próbáld újra" veszélyes a `POST`-nál. Az interjúztató a kétrészes felismerést akarja hallani: először, hogy az idempotencia olyan tulajdonság, amelyet *bele tudsz tervezni* (a `PUT`/`DELETE` természetesen biztonságossá tétele, és a `POST` ellátása **idempotency key**-jel, amikor nem lehet az), másodszor a finom konkurencia-részletet — két egyszerre érkező retry nem hajtódhat végre mindkettő, ezért a kulcs-ellenőrzésnek és az írásnak lockra vagy unique constraintre van szüksége. Ennek helyes megoldása a különbség aközött, hogy egyszer vagy kétszer terheled meg az ügyfelet, ezért implementálja minden komoly fizetési és kereskedelmi API.

A probléma

A megoldás: idempotency key-ek

Miért fontos

Kapcsolódó kérdések