تحسين أداء أنظمة استعلام النتائج تحت الضغط العالي

المشكلة

كل عام، عند إعلان نتائج الثانوية العامة، يحاول مئات الآلاف من الطلاب وأولياء الأمور الاستعلام عن نتائجهم خلال دقائق معدودة من الإعلان الرسمي. هذا النمط من «الضغط اللحظي الحاد» (Traffic Spike) يؤدي في العديد من الأنظمة المشابهة إلى:

• تعطل كامل للموقع أو بطء شديد يمتد لساعات
• أخطاء اتصال متكررة (Timeout، HTTP 500)
• تعذُّر الوصول إلى النتيجة عمليًا لساعات، رغم أن البيانات المطلوبة (نتيجة طالب واحد) صغيرة الحجم وثابتة فعليًا بعد لحظة الإعلان

النتيجة: تجربة محبطة لجمهور واسع في لحظة حسّاسة اجتماعيًا ونفسيًا، وضغط إعلامي وجماهيري كبير على الجهة المسؤولة عن النظام.

التحليل

بناءً على النمط الهندسي الشائع في هذا النوع من الأنظمة، غالبًا ما يعود السبب الجذري إلى تراكم عدة قرارات معمارية:

1. استعلام مباشر لقاعدة البيانات لكل طلب

لا توجد طبقة تخزين مؤقت (Cache) بين المستخدم وقاعدة البيانات. كل عملية «إدخال رقم الاكتتاب» تُنفّذ كاستعلام SQL كامل، رغم أن النتائج بيانات لا تتغير إطلاقًا بعد لحظة الإعلان الرسمي.

2. غياب طبقة توزيع وتخفيف الحمل (CDN)

كل الطلبات تصل مباشرة إلى خادم واحد أو عدد محدود من الخوادم، دون توزيع جغرافي أو طبقة وسيطة تمتص جزءًا كبيرًا من حجم الطلبات قبل وصولها إلى البنية الأساسية.

3. بنية مصمَّمة لحمل يومي عادي وليس لذروة استثنائية

غالبًا ما تُبنى الأنظمة الحكومية وتُختبر لتحمّل حركة استخدام يومية معتادة، بينما لحظة إعلان النتائج تمثّل ذروة قد تبلغ آلاف أضعاف المعدل الطبيعي خلال دقائق معدودة فقط.

4. عدم فصل «نافذة الذروة» عن دورة حياة النظام العادية

لا توجد استراتيجية تشغيلية مختلفة مخصصة ليوم الإعلان مقارنة ببقية أيام السنة — النظام يُعامَل بنفس الإعدادات على مدار العام.

الحل المقترح

حل معماري مرحلي، لا يتطلب إعادة بناء النظام من الصفر:

1. طبقة تخزين مؤقت (Caching) عبر Redis

فور لحظة إعلان النتائج، تُحمَّل جميع النتائج دفعة واحدة إلى Redis كخريطة مفتاح/قيمة (رقم الاكتتاب → النتيجة). كل استعلام لاحق يُخدَّم مباشرة من الذاكرة، دون لمس قاعدة البيانات إطلاقًا — استجابة بالميلي ثانية بدلًا من ثوانٍ أو تعطل كامل.

2. توليد لقطات ثابتة (Static Snapshots) عبر CDN

بما أن النتائج بيانات غير قابلة للتغيير (Immutable) بعد الإعلان، يمكن توليد ملفات JSON ثابتة صغيرة موزّعة عبر شبكة توصيل محتوى (Cloudflare أو Azure CDN). هذا يسمح بخدمة الغالبية العظمى من الطلبات دون وصولها إلى الخادم الأساسي إطلاقًا.

3. تجربة انتظار مرئية بدل رسائل الخطأ

بدلًا من صفحة خطأ 500 مربكة عند تجاوز السعة، تصميم «قائمة انتظار» واضحة (Queueing UX) يُظهر للمستخدم موقعه التقديري في الطابور — يحافظ على تجربة مقبولة نفسيًا حتى تحت ضغط استثنائي.

4. اختبار حمل مسبق قبل يوم الإعلان الفعلي

محاكاة الضغط المتوقع (بناءً على العدد الفعلي للطلاب المسجلين لهذا العام) بأسابيع قبل الموعد الحقيقي، بدلًا من اكتشاف نقاط الضعف يوم الحدث نفسه أمام الجمهور.

5. توسّع تلقائي مؤقت (Auto-Scaling) محصور بنافذة زمنية محددة

تفعيل موارد حوسبة إضافية (مثل Azure Container Apps أو مجموعات توسّع تلقائي مشابهة) فقط خلال الساعات المحيطة بموعد الإعلان الرسمي، ثم العودة للسعة الاعتيادية — كفاءة في التكلفة دون المساس بالأداء وقت الحاجة الفعلية.

القيمة المضافة

تحويل تجربة قد تمتد ساعات من التعطل والإحباط الجماهيري، إلى استجابة فورية (أقل من ثانية) لكل استعلام فردي — دون الحاجة لإعادة بناء النظام القائم بالكامل، بل عبر إضافة طبقات هندسية ذكية فوق البنية الحالية.