idempotency ਕੀ ਹੈ, ਅਤੇ idempotency keys retries ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹਨ?

Question

IT Interview Practice · Accepted Answer

**Idempotency** ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਕਾਰਵਾਈ ਨੂੰ **ਕਈ ਵਾਰ ਕਰਨ ਦਾ ਅਸਰ ਇੱਕ ਵਾਰ ਕਰਨ ਵਰਗਾ ਹੀ ਹੁੰਦਾ ਹੈ**। ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ networks ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹਨ: ਜਦੋਂ ਇੱਕ client ਇੱਕ request ਭੇਜਦਾ ਹੈ ਅਤੇ response ਕਦੇ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ server ਨੇ ਇਸਨੂੰ ਸੰਸਾਧਿਤ ਕੀਤਾ ਜਾਂ ਨਹੀਂ। ਜੇ ਇਹ retry ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ non-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` **ਨਹੀਂ** ਹੈ — ਇਹੀ ਥਾਂ ਹੈ ਜਿੱਥੋਂ duplicate charges ਅਤੇ duplicate 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 ਦਿੰਦਾ ਹੈ — customer ਤੋਂ ਇੱਕ ਵਾਰ charge ਹੁੰਦਾ ਹੈ। ਇਹ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਹੈ ਜਿਵੇਂ Stripe ਦਾ API ਕੰਮ ਕਰਦਾ ਹੈ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਇਹ ਸਵਾਲ ਉਹਨਾਂ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ ਜੋ happy path ਲਈ design ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਤੋਂ ਜੋ **failure** ਲਈ design ਕਰਦੇ ਹਨ, ਜੋ production ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਸਾਰ ਹੈ। Distributed systems ਗਾਰੰਟੀ ਦਿੰਦੇ ਹਨ ਕਿ timeouts ਅਤੇ ਅੰਸ਼ਿਕ ਅਸਫਲਤਾਵਾਂ *ਹੋਣਗੀਆਂ*, ਇਸ ਲਈ side effects ਵਾਲੇ ਕਿਸੇ ਵੀ endpoint — payments, orders, ਪੈਸੇ ਭੇਜਣਾ — ਨੂੰ ਇੱਕ retry ਕਹਾਣੀ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ "ਬੱਸ retry ਕਰੋ" `POST` ਲਈ ਖ਼ਤਰਨਾਕ ਹੈ। ਇੰਟਰਵਿਊ ਲੈਣ ਵਾਲਾ ਦੋ-ਭਾਗੀ ਸੂਝ ਸੁਣਨਾ ਚਾਹੁੰਦਾ ਹੈ: ਪਹਿਲਾ, ਕਿ idempotency ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ *design* ਕਰ ਸਕਦੇ ਹੋ (`PUT`/`DELETE` ਨੂੰ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ, ਅਤੇ ਜਦੋਂ `POST` ਨਹੀਂ ਹੋ ਸਕਦਾ ਤਾਂ ਇਸਨੂੰ ਇੱਕ **idempotency key** ਦੇਣਾ), ਅਤੇ ਦੂਜਾ, ਸੂਖਮ concurrency ਵੇਰਵਾ — ਇੱਕੋ ਸਮੇਂ ਆਉਂਦੇ ਦੋ retries ਦੋਵੇਂ ਨਹੀਂ ਚੱਲਣੇ ਚਾਹੀਦੇ, ਇਸ ਲਈ key check ਅਤੇ write ਨੂੰ ਇੱਕ lock ਜਾਂ unique constraint ਦੀ ਲੋੜ ਹੈ। ਇਸਨੂੰ ਸਹੀ ਕਰਨਾ customer ਤੋਂ ਇੱਕ ਵਾਰ charge ਕਰਨ ਅਤੇ ਦੋ ਵਾਰ charge ਕਰਨ ਵਿਚਕਾਰ ਫ਼ਰਕ ਹੈ, ਇਸੇ ਲਈ ਹਰ ਗੰਭੀਰ payments ਅਤੇ commerce API ਇਸਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਸਮੱਸਿਆ

ਹੱਲ: idempotency keys

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ