الحالة
تُدير دنتاليا إحدى أكبر شبكات عيادات الأسنان في أمريكا اللاتينية. حين تحجز موعداً عبر منصتهم، تختار من توفر فوري عبر أكثر من 65 عيادة ومئات الأطباء — كل منهم بجداول خاصة وأيام محجوبة واستثناءات توفر خاصة. كان النظام القديم يعاني من تعارض طلبات في صميم تدفق الحجز. حين يحاول مريضان حجز الموعد ذاته مع الطبيب ذاته في اللحظة ذاتها — وهو أمر شائع خلال نوافذ الحجز في الذروة — كان النظام يفحص التوفر لكليهما في آنٍ واحد ويجد الموعد متاحاً للاثنين ويؤكد الحجزين. تجد العيادة حينئذٍ مريضَين يصلان للكرسي ذاته. أعدنا تصميم مخطط التوفر ومعاملة الحجز من الصفر. القفل المتشائم بـ SELECT FOR UPDATE يضمن أن الفتحة محجوبة أثناء المعاملة بأكملها.
ما كان يجب أن يتغير
تسببت حالات التعارض في الحجز المتزامن في حجوزات مزدوجة بانتظام خلال ساعات الذروة. كان مريضان يحجزان الموعد ذاته في آنٍ واحد، كلاهما يتلقى تأكيدات، وكلاهما يصل إلى العيادة. علاوة على الضرر الذي يلحق بتجربة المريض، كل حادثة تتطلب إعادة جدولة يدوية ووقت أحد أعضاء فريق العيادة.
لقد تغيرت
إعادة تصميم المخطط: التوفر يُحسب من قوالب الجداول + استثناءات التجاوز (وليس من جدول فتحة لكل صف). القفل المتشائم على معاملة الحجز: SELECT FOR UPDATE عند اكتساب الفتحة، محتجَز طوال المدة الكاملة. استعلامات التوفر المبنية على القوالب تعمل بشكل أسرع وتتوسع لأي عدد من العيادات. نشر Docker للتوافق عبر جميع البيئات.
ما حصل عليه العميل
- 01 قفل DB المتشائم — تعارض الطلبات مستحيل
- 02 65+ عيادة ومئات الأطباء على منصة واحدة
- 03 توفر مبني على القوالب — مخطط نظيف في نطاق واسع
- 04 Docker — متوافق من التطوير إلى الإنتاج
