Idempotency என்றால் என்ன, மேலும் idempotency keys retries-ஐ எப்படிப் பாதுகாப்பாக்குகின்றன?

Question

IT Interview Practice · Accepted Answer

**Idempotency** என்பது ஒரு operation-ஐ **பல முறை செய்வது ஒரு முறை செய்வதன் அதே விளைவைக் கொண்டிருப்பது**. நெட்வொர்க்குகள் நம்பகமற்றவை என்பதால் இது முக்கியம்: ஒரு client ஒரு request அனுப்பி response ஒருபோதும் வராதபோது, server அதைச் செயலாக்கியதா என்று அதனால் சொல்ல முடியாது. அது 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 தர்க்க ரீதியான operation-க்கு ஒரு **தனித்துவமான 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-ஐயும் அளிக்கிறது — customer ஒரு முறை மட்டுமே charge செய்யப்படுகிறார். Stripe-இன் API சரியாக இப்படித்தான் வேலை செய்கிறது.

## இது ஏன் முக்கியம்

இந்தக் கேள்வி happy path-க்காக design செய்யும் engineers-ஐ **failure**-க்காக design செய்பவர்களிடமிருந்து பிரிக்கிறது, இதுதான் production reliability-இன் அடிப்படை. Distributed systems timeouts மற்றும் partial failures *நடக்கும்* என்பதை உறுதிசெய்கின்றன, எனவே side effects கொண்ட எந்த endpoint-ம் — payments, orders, பணம் அனுப்புதல் — ஒரு retry கதை தேவை, மேலும் `POST`-க்கு "வெறுமனே retry செய்" ஆபத்தானது. Interviewer இரு-பகுதி நுண்ணறிவைக் கேட்க விரும்புகிறார்: முதலில், idempotency என்பது நீங்கள் *design செய்யக்கூடிய* ஒரு property (`PUT`/`DELETE`-ஐ இயற்கையாகப் பாதுகாப்பாக்குதல், மற்றும் `POST`-க்கு அது முடியாதபோது ஒரு **idempotency key** கொடுத்தல்), இரண்டாவதாக, நுட்பமான concurrency விவரம் — ஒரே நேரத்தில் வரும் இரண்டு retries இரண்டும் இயங்கக்கூடாது, எனவே key check மற்றும் write-க்கு ஒரு lock அல்லது unique constraint தேவை. இதைச் சரியாகச் செய்வது ஒரு customer-ஐ ஒரு முறை charge செய்வதற்கும் இருமுறை charge செய்வதற்கும் இடையிலான வேறுபாடு, அதனால்தான் ஒவ்வொரு தீவிர payments மற்றும் commerce API-ம் அதைச் செயல்படுத்துகிறது.

சிக்கல்

தீர்வு: idempotency keys

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்