X'inhi l-idempotency, u kif l-idempotency keys jagħmlu r-retries sikuri?

Question

IT Interview Practice · Accepted Answer

L-**idempotency** tfisser li twettaq operazzjoni **diversi darbiet ikollha l-istess effett bħal meta twettaqha darba**. Timporta għax in-networks huma mhux affidabbli: meta client jibgħat request u r-response qatt ma jasal, ma jistax jgħid jekk is-server ipproċessahx. Jekk jerġa' jipprova, operazzjoni non-idempotent tista' taħdem darbtejn.

## Il-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`, u `DELETE` huma naturalment idempotent, u għalhekk ir-retry tagħhom huwa sikur. `POST` **mhux** — dan huwa eżatt minn fejn jiġu l-charges dupplikati u l-orders dupplikati.

## Is-soluzzjoni: idempotency keys

Il-client jiġġenera **key uniku** (ġeneralment UUID) għall-operazzjoni loġika u jibagħtu f'header. Is-server jaħżen il-key mar-riżultat; jekk l-istess key jasal mill-ġdid, jirritorna r-riżultat **maħżun** minflok ma jerġa' jeżegwixxi.

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

L-**istess key** fir-retry jagħti l-istess `200` u l-istess payment — il-klijent jiġi charged darba. Dan huwa eżatt kif taħdem l-API ta' Stripe.

## Għaliex huwa importanti

Din il-mistoqsija tifred l-inġiniera li jiddisinjaw għall-happy path minn dawk li jiddisinjaw għall-**falliment**, li huwa dak li tirrigwarda l-affidabbiltà tal-produzzjoni. Is-sistemi distribwiti jiggarantixxu li t-timeouts u l-fallimenti parzjali *se* jiġru, u għalhekk kull endpoint b'side effects — payments, orders, jibgħat il-flus — jeħtieġ storja ta' retry, u "sempliċiment erġa' pprova" huwa perikoluż għal `POST`. L-intervistatur irid jisma' l-għarfien f'żewġ partijiet: l-ewwel, li l-idempotency hija proprjetà li tista' *tiddisinjaha* (billi tagħmel `PUT`/`DELETE` naturalment sikuri, u tagħti lil `POST` **idempotency key** meta ma jistax ikun), u t-tieni, id-dettall sottili tal-konkorrenza — żewġ retries li jaslu f'daqqa m'għandhomx it-tnejn jeżegwixxu, u għalhekk il-check tal-key u l-kitba jeħtieġu lock jew unique constraint. Li tagħmel dan sew hija d-differenza bejn li tikkarga klijent darba u li tikkargah darbtejn, u għalhekk kull API serja ta' payments u kummerċ timplimentaha.

Il-problema

Is-soluzzjoni: idempotency keys

Għaliex huwa importanti

Mistoqsijiet relatati