Idempotency भनेको के हो, र idempotency key हरूले retry लाई कसरी सुरक्षित बनाउँछन्?

Question

IT Interview Practice · Accepted Answer

**Idempotency** को अर्थ एउटा operation **धेरै पटक गर्दा एक पटक गरे जस्तै असर हुन्छ** भन्ने हो। यो महत्त्वपूर्ण छ किनभने network हरू अविश्वसनीय हुन्छन्: जब कुनै client ले request पठाउँछ र response कहिल्यै आउँदैन, यसले server ले process गर्‍यो कि गरेन थाहा पाउन सक्दैन। यदि यसले retry गर्‍यो भने, non-idempotent operation दुई पटक चल्न सक्छ।

## समस्या

```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`, र `DELETE` स्वाभाविक रूपमा idempotent छन्, त्यसैले तिनलाई retry गर्नु सुरक्षित छ। `POST` **छैन** — duplicate charge र duplicate order ठ्याक्कै यहीँबाट आउँछन्।

## समाधान: idempotency key हरू

Client ले तार्किक operation का लागि एउटा **अद्वितीय key** (सामान्यतया एउटा UUID) सिर्जना गर्छ र यसलाई एउटा header मा पठाउँछ। Server ले key लाई परिणामसँग भण्डारण गर्छ; यदि उही key फेरि आयो भने, यसले पुनः-execute गर्नुको सट्टा **भण्डारण गरिएको** परिणाम फर्काउँछ।

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

Retry मा **उही key** ले उही `200` र उही payment दिन्छ — ग्राहकलाई एक पटक मात्र charge गरिन्छ। Stripe को API ठ्याक्कै यसरी काम गर्छ।

## यो किन महत्त्वपूर्ण छ

यो प्रश्नले happy path का लागि design गर्ने engineer हरूलाई **असफलता** का लागि design गर्नेहरूबाट छुट्याउँछ, जुन production विश्वसनीयताको सार हो। Distributed system हरूले timeout र आंशिक असफलता *हुनेछन्* भन्ने ग्यारेन्टी गर्छन्, त्यसैले side effect भएको कुनै पनि endpoint — payment, order, पैसा पठाउने — लाई retry रणनीति चाहिन्छ, र `POST` का लागि "बस retry गर" खतरनाक छ। Interviewer ले दुई-भागको अन्तर्दृष्टि सुन्न चाहन्छन्: पहिलो, कि idempotency तपाईंले *design गर्न सक्ने* गुण हो (`PUT`/`DELETE` लाई स्वाभाविक रूपमा सुरक्षित बनाउने, र `POST` लाई त्यो नसक्दा एउटा **idempotency key** दिने), र दोस्रो, सूक्ष्म concurrency विवरण — एकैचोटि आइपुग्ने दुई retry दुवैले execute गर्नु हुँदैन, त्यसैले key जाँच र लेखनलाई एउटा lock वा unique constraint चाहिन्छ। यो सही पार्नु ग्राहकलाई एक पटक charge गर्ने र दुई पटक charge गर्नेबीचको फरक हो, यही कारण हरेक गम्भीर payment र commerce API ले यो लागू गर्छ।

समस्या

समाधान: idempotency key हरू

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू