Mitä on idempotency, ja miten idempotency-avaimet tekevät uudelleenyrityksistä turvallisia?

Question

IT Interview Practice · Accepted Answer

**Idempotency** tarkoittaa, että operaation suorittaminen **useita kertoja vaikuttaa samoin kuin sen suorittaminen kerran**. Sillä on merkitystä, koska verkot ovat epäluotettavia: kun client lähettää pyynnön eikä vastaus koskaan saavu, se ei voi tietää käsittelikö palvelin sen. Jos se uudelleenyrittää, ei-idempotentti operaatio saattaa ajaa kahdesti.

## Ongelma

```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` ja `DELETE` ovat luonnostaan idempotentteja, joten niiden uudelleenyrittäminen on turvallista. `POST` **ei** ole — juuri tästä duplikaattiveloitukset ja duplikaattitilaukset syntyvät.

## Ratkaisu: idempotency-avaimet

Client generoi **uniikin avaimen** (yleensä UUID) loogiselle operaatiolle ja lähettää sen headerissa. Palvelin tallentaa avaimen tuloksineen; jos sama avain saapuu uudelleen, se palauttaa **tallennetun** tuloksen sen sijaan että suorittaisi uudelleen.

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

**Sama avain** uudelleenyrityksessä tuottaa saman `200`:n ja saman maksun — asiakkaalta veloitetaan kerran. Juuri näin Stripen API toimii.

## Miksi se on tärkeää

Tämä kysymys erottaa insinöörit, jotka suunnittelevat happy pathille, niistä, jotka suunnittelevat **epäonnistumiselle**, mistä tuotannon luotettavuudessa on kyse. Hajautetut järjestelmät takaavat, että timeoutit ja osittaiset viat *tulevat* tapahtumaan, joten mikä tahansa endpoint, jolla on sivuvaikutuksia — maksut, tilaukset, rahan lähetys — tarvitsee retry-tarinan, ja "vain uudelleenyritä" on vaarallista `POST`ille. Haastattelija haluaa kuulla kaksiosaisen oivalluksen: ensinnäkin, että idempotency on ominaisuus, jonka voit *suunnitella sisään* (tehden `PUT`/`DELETE`stä luonnostaan turvallisia ja antaen `POST`ille **idempotency-avaimen**, kun se ei muuten ole), ja toiseksi, hienovaraisen concurrency-yksityiskohdan — kahden yhtä aikaa saapuvan uudelleenyrityksen ei saa molempien suorittaa, joten avaintarkistus ja kirjoitus tarvitsevat lukon tai unique constraintin. Tämän oikein saaminen on ero asiakkaan veloittamisessa kerran ja kahdesti, minkä vuoksi jokainen vakavasti otettava maksu- ja kaupankäynti-API toteuttaa sen.

Ongelma

Ratkaisu: idempotency-avaimet

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset