idempotency کیا ہے، اور idempotency keys retries کو کیسے محفوظ بناتے ہیں؟

Question

IT Interview Practice · Accepted Answer

**Idempotency** کا مطلب ہے کہ کسی آپریشن کو **کئی بار انجام دینے کا وہی اثر ہوتا ہے جو اسے ایک بار انجام دینے کا**۔ یہ اس لیے اہم ہے کیونکہ نیٹ ورکس ناقابلِ اعتماد ہیں: جب کوئی client ایک request بھیجتا ہے اور response کبھی نہیں پہنچتا، تو یہ نہیں بتا سکتا کہ آیا server نے اسے پروسیس کیا۔ اگر یہ retry کرے، تو ایک غیر idempotent آپریشن دو بار چل سکتا ہے۔

## مسئلہ

```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` **نہیں** ہے — بالکل یہیں سے ڈپلیکیٹ charges اور ڈپلیکیٹ orders آتے ہیں۔

## حل: idempotency keys

client اس منطقی آپریشن کے لیے ایک **منفرد key** (عام طور پر ایک UUID) بناتا ہے اور اسے ایک header میں بھیجتا ہے۔ server key کو نتیجے کے ساتھ محفوظ کرتا ہے؛ اگر وہی key دوبارہ پہنچے، تو یہ دوبارہ عملدرآمد کرنے کے بجائے **محفوظ شدہ** نتیجہ واپس کرتا ہے۔

```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 کے لیے ڈیزائن کرتے ہیں ان سے الگ کرتا ہے جو **ناکامی** کے لیے ڈیزائن کرتے ہیں، جو production کی قابلِ اعتمادی کا اصل معاملہ ہے۔ Distributed systems ضمانت دیتے ہیں کہ timeouts اور جزوی ناکامیاں *ہوں گی*، اس لیے کسی بھی ضمنی اثر (side effect) والے endpoint کو — payments، orders، پیسے بھیجنا — ایک retry حکمتِ عملی درکار ہے، اور `POST` کے لیے "بس retry کر لو" خطرناک ہے۔ انٹرویو لینے والا دو حصوں کی بصیرت سننا چاہتا ہے: پہلی، کہ idempotency ایک ایسی خصوصیت ہے جسے آپ *ڈیزائن میں شامل* کر سکتے ہیں (`PUT`/`DELETE` کو فطری طور پر محفوظ بناتے ہوئے، اور `POST` کو جب وہ نہ ہو سکے تو ایک **idempotency key** دیتے ہوئے)، اور دوسری، باریک concurrency تفصیل — بیک وقت پہنچنے والی دو retries دونوں کو عملدرآمد نہیں کرنا چاہیے، اس لیے key کی جانچ اور write کو ایک lock یا unique constraint درکار ہے۔ اسے درست کرنا گاہک سے ایک بار charge کرنے اور دو بار charge کرنے کے درمیان کا فرق ہے، یہی وجہ ہے کہ ہر سنجیدہ payments اور commerce API اسے نافذ کرتی ہے۔

مسئلہ

حل: idempotency keys

یہ کیوں اہم ہے

متعلقہ سوالات