Idempotency શું છે, અને idempotency keys retries ને કેવી રીતે સલામત બનાવે છે?

Question

IT Interview Practice · Accepted Answer

**Idempotency** નો અર્થ છે operation ને **અનેક વાર કરવાની અસર એક વાર કરવા જેવી જ છે**. તે મહત્વનું છે કારણ કે networks અવિશ્વસનીય છે: જ્યારે client request મોકલે અને response ક્યારેય ન આવે, ત્યારે તે કહી શકતું નથી કે server એ તેને process કર્યું કે નહીં. જો તે retry કરે, તો non-idempotent operation બે વાર ચાલી શકે.

## સમસ્યા

```text
Client ──POST /payments {$100}──▶ Server   ($100 ચાર્જ ✓)
Client ◀────────X (timeout)────── Server   (response ખોવાયો)
Client ──POST /payments {$100}──▶ Server   ($100 ફરીથી ચાર્જ ✗ → $200!)
```

`GET`, `PUT`, અને `DELETE` કુદરતી રીતે idempotent છે, તેથી તેમને retry કરવું સલામત છે. `POST` **નથી** — ડુપ્લિકેટ charges અને ડુપ્લિકેટ orders બરાબર અહીંથી આવે છે.

## ઉકેલ: idempotency keys

Client logical operation માટે એક **unique key** (સામાન્ય રીતે UUID) બનાવે છે અને તેને header માં મોકલે છે. Server key ને result સાથે સંગ્રહે છે; જો એ જ key ફરી આવે, તો તે ફરી execute કરવાને બદલે **સંગ્રહાયેલ** result પરત કરે છે.

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

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

```text
Idempotency-Key સાથે request મળે ત્યારે Server logic:
  1. store માં key શોધો (દા.ત. Redis/DB).
  2. મળે તો → સાચવેલ response પરત કરો (ફરી charge નહીં).      ← retry કેસ
  3. ન મળે તો → process કરો, સાચવો (key → response), પછી પરત કરો.
  (concurrent retries બે વાર execute ન કરે એ માટે step 3 ને transaction / lock માં લપેટો.)
```

retry પર **એ જ key** એ જ `200` અને એ જ payment આપે છે — customer ને એક વાર charge થાય છે. Stripe નું API બરાબર આ રીતે કામ કરે છે.

## આ શા માટે મહત્વનું છે

આ પ્રશ્ન happy path માટે design કરતા engineers ને **failure** માટે design કરતાઓથી અલગ પાડે છે, જે production reliability નો સાર છે. Distributed systems ખાતરી આપે છે કે timeouts અને partial failures *થશે જ*, તેથી side effects વાળા કોઈપણ endpoint ને — payments, orders, પૈસા મોકલવા — retry વ્યૂહરચના જોઈએ, અને "ફક્ત retry" એ `POST` માટે ખતરનાક છે. Interviewer બે-ભાગની સૂઝ સાંભળવા માગે છે: પ્રથમ, કે idempotency એ ગુણધર્મ છે જે તમે *design માં નાખી* શકો (`PUT`/`DELETE` ને કુદરતી રીતે સલામત બનાવીને, અને `POST` ને જ્યારે ન બની શકે ત્યારે **idempotency key** આપીને), અને બીજું, સૂક્ષ્મ concurrency વિગત — એકસાથે આવતા બે retries બંને execute ન થવા જોઈએ, તેથી key check અને write ને lock કે unique constraint જોઈએ. આને સાચું મેળવવું એ customer ને એક વાર charge કરવા અને બે વાર charge કરવા વચ્ચેનો તફાવત છે, એટલે જ દરેક ગંભીર payments અને commerce API તેને અમલમાં મૂકે છે.

સમસ્યા

ઉકેલ: idempotency keys

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો