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   (charges $100 ✓)
Client ◀────────X (timeout)────── Server   (response lost)
Client ──POST /payments {$100}──▶ Server   (charges $100 AGAIN ✗ → $200!)
```

`GET`, `PUT`, और `DELETE` स्वाभाविक रूप से idempotent हैं, इसलिए उन्हें retry करना सुरक्षित है। `POST` **नहीं** है — duplicate charges और duplicate orders ठीक यहीं से आते हैं।

## समाधान: idempotency keys

Client logical operation के लिए एक **unique key** (आमतौर पर एक UUID) generate करता है और उसे एक header में भेजता है। Server key को result के साथ store करता है; अगर वही key फिर से आती है, तो वह फिर से execute करने के बजाय **stored** result लौटाता है।

```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 देती है — customer से एक बार charge होता है। Stripe का API ठीक इसी तरह काम करता है।

## यह क्यों महत्वपूर्ण है

यह सवाल उन engineers को अलग करता है जो happy path के लिए design करते हैं उनसे जो **failure** के लिए design करते हैं, जो production reliability का सार है। Distributed systems गारंटी देते हैं कि timeouts और partial failures *होंगे*, इसलिए side effects वाले किसी भी endpoint को — payments, orders, पैसा भेजना — एक retry रणनीति चाहिए, और `POST` के लिए "बस retry कर दो" खतरनाक है। 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

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न