Post by Hossam Farouz
Senior Web Developer | PHP | Laravel at Beetleware
**إزاي كـ Software Architect تتجنب "فخ" الـ Race Condition في أنظمة الحجوزات؟ 🚀** أكبر غلطة ممكن المبرمج يقع فيها وهو بيبني نظام حجوزات (أو بيجاوب في إنترفيو تقني) هي الاعتماد على الـ Validation العادي بس. المشكلة إن لو اتنين يوزرز داسوا "تأكيد الحجز" في نفس اللحظة (Millisecond)، الطلبين هيعدوا من الـ Validation قبل ما الداتا تتسجل، والنتيجة؟ حجز مزدوج كارثي لنفس الموعد! علشان تبني سيستم قوي ومستقر، لازم تفكر بعقلية الـ **Defense in Depth** (الحماية متعددة الطبقات). إليك التلخيص المعماري لأقوى الحلول: * **1️⃣ القفل المتشائم (Pessimistic Locking):** الحل الأساسي جوه الداتابيز باستخدام SELECT ... FOR UPDATE. السيستم بيعمل "قفل" على الموعد لأول طلب يوصل. لو الطلب التاني وصل في نفس اللحظة، هيُجبر إنه ينتظر (Wait) لحد ما الأول يخلص ويسجل الحجز، ولما ييجي يكمل هيلاقي الحالة اتغيرت، فيترفض بأمان. (أفضل كتير في الحجوزات من الـ Optimistic Locking اللي بيستهلك الموارد في محاولات فاشلة). * **2️⃣ أقفال الـ Redis (Distributed Locks - Mutex):** ليه نرهق الداتابيز أساساً؟ بمجرد ما اليوزر الأول يطلب الحجز، بنعمل قفل مؤقت على **Redis**. ولأن Redis بيشتغل بنظام Single Thread، هيرفض طلب اليوزر التاني فوراً من الباب الخارجي من غير ما نعمل أي استعلام في قواعد البيانات. ده بيوفر أداء جبار للسيستم. * **3️⃣ قيود قاعدة البيانات (Unique Constraints):** حائط الصد الأخير! بنبني Composite Unique Index على مستوى الداتابيز (مثلاً: doctor_id و appointment_time). حتى لو الكود نفسه فشل أو حصلت مشكلة في الأقفال، الداتابيز مستحيل تقبل حجزين لنفس الدكتور في نفس الوقت، وهترمي Exception نقدر نتعامل معاه بسهولة. * **4️⃣ الطوابير التسلسلية (Event Queues):** لو السيستم بيواجه ترافيك مرعب (زي حجز تذاكر ماتشات الأهلي أو حفلات كبيرة)، ممنوع الطلبات تلمس الداتابيز مباشرة. بنرمي كل الطلبات في طابور (زي RabbitMQ)، والـ Workers بتسحبها واحد ورا التاني بالترتيب (FIFO). أول طلب بياخد التذكرة، والطلبات اللي وراه بتترفض بانتظام. 🎯 **الخلاصة المعمارية:** السيستم اللي مابيعطلش مش بيعتمد على حل واحد. هندسة النظام الصح بتتبني كده: "استخدام **Redis Lock** لصد الضغط السريع من بره، مع **Pessimistic Lock** لمعالجة الداتا بأمان جوه الـ Transaction، وأخيراً **Unique Index** في الداتابيز كضمان أخير يستحيل اختراقه." #SystemDesign #SoftwareEngineering #Backend #Laravel #Architecture #WebDevelopment #Redis