ما هي الـ idempotency، وكيف تجعل idempotency keys إعادة المحاولة آمنة؟

Question

IT Interview Practice · Accepted Answer

الـ **Idempotency** تعني أن أداء عملية **عدة مرات له الأثر نفسه لأدائها مرة واحدة**. وهي مهمة لأن الشبكات غير موثوقة: حين يرسل العميل طلبًا ولا تصل الاستجابة أبدًا، لا يستطيع الجزم بأن الخادم عالجه. وإذا أعاد المحاولة، فقد تُنفَّذ عملية غير 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 بطبيعتها، فإعادة محاولتها آمنة. أمّا `POST` فـ **ليس** كذلك — ومن هنا بالضبط تأتي عمليات الخصم المكرّرة والطلبات المكرّرة.

## الحل: idempotency keys

يولّد العميل **مفتاحًا فريدًا** (UUID عادةً) للعملية المنطقية ويرسله في header. يخزّن الخادم المفتاح مع النتيجة؛ فإذا وصل المفتاح نفسه ثانيةً، أرجع النتيجة **المخزّنة** بدل إعادة التنفيذ.

```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.)
```

الـ **مفتاح نفسه** عند إعادة المحاولة يعطي `200` نفسه والدفعة نفسها — فيُخصَم من العميل مرة واحدة. هكذا تعمل API الخاصة بـ Stripe بالضبط.

## لماذا يهم

يفصل هذا السؤال المهندسين الذين يصمّمون للمسار السعيد عمن يصمّمون للـ **فشل**، وهو جوهر موثوقية الإنتاج. تضمن الأنظمة الموزّعة أن انقطاعات المهلة والأعطال الجزئية *ستقع*، فأيّ endpoint له آثار جانبية — مدفوعات، طلبات، تحويل أموال — يحتاج قصة إعادة محاولة، و"أعِد المحاولة فحسب" خطير مع `POST`. يريد المُقابِل سماع البصيرة ذات الشقّين: أولًا، أن الـ idempotency خاصية *تصمّمها* (بجعل `PUT`/`DELETE` آمنة طبيعيًّا، ومنح `POST` **idempotency key** حين لا يستطيع)، وثانيًا، التفصيل الدقيق في التزامن — يجب ألّا تُنفَّذ إعادتا محاولة تصلان معًا كلتاهما، فيحتاج فحص المفتاح والكتابة إلى lock أو unique constraint. إتقان هذا هو الفرق بين خصم مبلغ من العميل مرة واحدة وخصمه مرتين، ولهذا تُطبّقه كل API مدفوعات وتجارة جادّة.

المشكلة

الحل: idempotency keys

لماذا يهم

أسئلة ذات صلة