يا صاحبي، خلينا نتكلم عن إزاي تحمي الـ API بتاعك من الطلبات المتكررة!

طيب ما نشوف، كلنا عارفين إن الشبكات دي مش دايماً مستقرة وكمان الناس بتحاول تضغط على زرار "Submit" مرتين بالغلط. فدا يوصل لمشكلة كبيرة، يعني لو العميل ضغط على "Pay" مرتين، ممكن الفلوس تتخصم مرتين! 🤯

طيب، إيه هو المفهوم اللي هيساعدنا في حل هذة المشكلة؟

ده شوية حاجة اسمها Idempotency. بص يا سيدي، هي ببساطة تعني إن لو طلبت حاجة مرة أو 10 مرات بنفس البيانات، النتيجة النهائية تفضل واحدة ومن غير ما تحدث نفس البيانات أكتر من مرة.

يعني لو حذفت طلب مرة، وحاولت تحذفه تاني، مفيش حاجة جديدة هتحصل. ده شيء مضمون! 🙌

إيه اللي بيحصل فعلاً؟

اللي بيحصل كتير جدًا هو أن الـ Frontend تقيل، أو الشبكة فيها Lag، أو المستخدم ضغط على الزرار مرتين، أو الـ Client عمل Retry بسبب Timeout. مثلاً، لو العميل ضغط على "Pay" مرتين بالغلط، مش منطقي إن الطلب يتسجل مرتين ومش مقبول إن الفلوس تتخصم مرتين.

الفكرة هنا إن السيرفر يرجع نفس الرد اللي رجعه في أول طلب، من غير ما يعيد تنفيذ العملية. يعني لو اتبعت الطلبات مرة تانية، السيرفر يقولك: "أنت متأكد إنك عايز تفعل ده تاني؟ أنا قدرت عليك الأول!" 😄

هل كل الطلبات لازم تكون Idempotent؟

الإجابة: لا ❌، هنا لازم نفرق بين مفهومين مهمين:

1. Safe Requests زي GET، مبتغيّرش أي داتا وتقدر تنفذها ألف مرة ومفيش سide effects. مثلاً، لما تروح تشتري كوباية قهوة، تقدر تسأل عن الأنواع اللي موجودة عند البائع، وأنت مخافش إن تغير حاجة.

2. Idempotent Requests زي PUT وDELETE، بتغير الداتا، بس تكرارها مش المفروض يغير النتيجة بعد أول مرة. يعني لو حذفت طلب، وحاولت تحذفه تاني، مفيش حاجة جديدة هتحصل. مثل ما لو كنت تجيب الكشك وطلبت كوباية قهوة، وطلبتها تاني، البائع هيتقال لك: "أنا قدرت عليك الأولى يا فندم!" 😂

ليه الموضوع ده مهم؟

الموضوع ده مهم جدًا، ومش رفاهية 🚨. لأن الشبكات مش دايمًا مستقرة، والـ Timeouts بتحصل، والـ Retries بتحصل غصب عنك. لو الـ API بتاعك مش Idempotent، ممكن تواجه مشاكل زي:

• Duplicate Orders
• Duplicate Payments
• Data Inconsistency
• Bugs ملهاش آخر

علشان كده، خليك ماشي بالقاعدة الذهبية: Design for Retries. اعتبر إن أي طلب ممكن يتبعت أكتر من مرة.

إزاى نخلي الـ API Idempotent؟

فيه أكتر من مستوى للحل:

1. على مستوى الـ Frontend

حل بسيط لكن مش كفاية لوحده: Disable زرار الـ Submit بعد أول Click، Loading State، Prevent double clicks. ده بيقلل المشكلة، بس عمره ما يمنعها 100%.

2. على مستوى الـ Backend (الحل الحقيقي) 🗝

استخدم Idempotency Key، وهو Token فريد أو Transaction ID أو UUID. الـ Flow بيكون كده:

• الـ Client يبعت Idempotency-Key مع الـ Request
• السيرفر يشيّك عليه في الداتابيز أو الكاش
• لو الـ Key موجود: رجّع نفس الـ Response القديمة
• لو مش موجود: خزّنه، نفّذ العملية، واحفظ النتيجة

كده، نفس الـ Request، نفس الـ Response، تنفيذ واحد وبس ✅

3. مع أنظمة الدفع (أفضل سيناريو 💳)

لو بتتعامل مع Stripe، Paymob، PayPal، أو أي Payment Provider، غالباً بيبقى عندك transactionId أو paymentIntentId. الحل الذكي:

• خزّن الـ ID ده في DB
• اعمل عليه Unique Constraint
• لو الـ Request اتبعت تاني: الإضافة التانية هتفشل بسبب الـ Unique Constraint
• انت تتعامل مع الخطأ بهدوء وترجع نفس النتيجة

حل بسيط، عملي، وفعال جدًا 🔥

ملاحظة مهمة (Senior Tip ⚠️)

من عيوب حل الـ Unique Constraint إنك أحيانًا تبعت Request للداتابيز وأنت عارف إنه هيفشل. بس ده Failure متوقع ومسيطر عليه وأرخص بكتير من إنك تتعامل مع Duplicate Payments بعد كده 😄

الخلاصة 🧠

Idempotency مش مجرد مصطلح نظري، ده أسلوب تفكير وطريقة تصميم بتحمي الـ APIs بتاعتك وبتوفّر عليك Bugs وكوارث إنتاجية. لو الـ API بتاعك بيتعامل مع فلوس، Orders، عمليات حساسة، اسأل نفسك دايمًا: لو الـ Request اتكرر… هل النظام عندي هيفضل سليم؟ لو الإجابة آه، بقى انت ماشي في السكة الصح 👌