Kas yra idempotency ir kaip idempotency keys daro retries saugius?

Question

IT Interview Practice · Accepted Answer

**Idempotency** reiškia, kad operacijos atlikimas **kelis kartus turi tą patį efektą kaip atlikimas vieną kartą**. Tai svarbu, nes tinklai nepatikimi: kai klientas siunčia užklausą, o atsakymas niekada neateina, jis negali pasakyti, ar serveris ją apdorojo. Jei jis pakartoja, ne-idempotent operacija gali įvykti du kartus.

## Problema

```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` ir `DELETE` yra natūraliai idempotent, todėl juos kartoti saugu. `POST` **nėra** — būtent iš čia atsiranda dvigubi nuskaitymai ir dvigubi orders.

## Sprendimas: idempotency keys

Klientas sugeneruoja **unikalų raktą** (paprastai UUID) loginei operacijai ir siunčia jį header. Serveris saugo raktą su rezultatu; jei tas pats raktas ateina vėl, jis grąžina **išsaugotą** rezultatą, užuot vykdęs iš naujo.

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

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

```text
Serverio logika gavus užklausą su Idempotency-Key:
  1. Ieškok rakto saugykloje (pvz. Redis/DB).
  2. Jei rastas → grąžink išsaugotą atsakymą (jokio pakartotinio nuskaitymo).  ← retry atvejis
  3. Jei ne     → apdorok, išsaugok (key → response), tada grąžink.
  (Apgaubk 3 žingsnį transakcija / lock, kad lygiagretūs retry nevykdytų dukart.)
```

**Tas pats raktas** kartojant duoda tą patį `200` ir tą patį mokėjimą — klientas nuskaitomas vieną kartą. Būtent taip veikia Stripe API.

## Kodėl tai svarbu

Šis klausimas atskiria inžinierius, projektuojančius laimingam keliui (happy path), nuo tų, kurie projektuoja **gedimui**, o būtent apie tai ir yra production patikimumas. Paskirstytos sistemos garantuoja, kad timeouts ir daliniai gedimai *įvyks*, todėl bet kuris endpoint su šalutiniais efektais — mokėjimai, orders, pinigų siuntimas — reikalauja retry strategijos, o „tiesiog pakartok“ yra pavojinga `POST` atveju. Interviuotojas nori išgirsti dviejų dalių įžvalgą: pirma, kad idempotency yra savybė, kurią gali *įprojektuoti* (padarant `PUT`/`DELETE` natūraliai saugius ir suteikiant `POST` **idempotency key**, kai jis negali būti saugus); antra, subtilią lygiagretumo detalę — du retry, atėję vienu metu, neturi abu vykdytis, todėl rakto patikra ir įrašymas reikalauja lock arba unique constraint. Teisingas to atlikimas yra skirtumas tarp kliento nuskaitymo vieną kartą ir nuskaitymo du kartus, todėl kiekviena rimta mokėjimų ir prekybos API tai įgyvendina.

Problema

Sprendimas: idempotency keys

Kodėl tai svarbu

Susiję klausimai