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` **নয়** — ঠিক এখান থেকেই ডুপ্লিকেট charge আর ডুপ্লিকেট order আসে।

## সমাধান: idempotency key

Client logical operation-এর জন্য একটি **unique 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 দেয় — customer একবারই charge হয়। Stripe-এর API ঠিক এভাবেই কাজ করে।

## এটি কেন গুরুত্বপূর্ণ

এই প্রশ্ন যারা happy path-এর জন্য design করে তাদের যারা **failure**-এর জন্য design করে তাদের থেকে আলাদা করে, যা production reliability-র মূল কথা। Distributed system নিশ্চিত করে যে timeout আর partial failure *ঘটবেই*, তাই side effect সহ যেকোনো endpoint — payment, order, টাকা পাঠানো — এর একটি retry গল্প দরকার, আর "just retry" `POST`-এর জন্য বিপজ্জনক। Interviewer দুই-অংশের অন্তর্দৃষ্টি শুনতে চান: প্রথমত, idempotency এমন একটি বৈশিষ্ট্য যা আপনি *design করে ঢোকাতে* পারেন (`PUT`/`DELETE`-কে স্বাভাবিকভাবে safe করা, এবং `POST` যখন পারে না তখন এটিকে একটি **idempotency key** দেওয়া), এবং দ্বিতীয়ত, সূক্ষ্ম concurrency বিশদ — একসাথে আসা দুটি retry উভয়ই execute করা উচিত নয়, তাই key check আর write-এর একটি lock বা unique constraint দরকার। এটি সঠিক করা একটি customer-কে একবার charge করা আর দুবার charge করার মধ্যে পার্থক্য, সেজন্যই প্রতিটি গুরুতর payment ও commerce API এটি বাস্তবায়ন করে।

সমস্যা

সমাধান: idempotency key

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন