يسعد مساكن أصدقائي،
كل سنة، من أيام النظام السابق، مع صدور نتائج التاسع أو البكالوريا، بيتوقف موقع وزارة التربية لفترة طويلة، والناس بتغلي، وبتتحول لحالة من التوتر والإنتظار.
كنت دائما متأمل إنه مع مرور الزمن والتطور التقني، يصير في تحسن فعلي بالبنية التحتية لهالخدمة الحساسة، خصوصا بعد إطلاق تطبيق رسمي للنتائج تابع لوزارة التربية السورية، لكن للأسف، رغم التغييرات بالشكل، جوهر المشكلة هو هو يعني نفس Performance، نفس زمن ال Downtime.
قبل فترة، وقت صدرت نتائج البكالوريا، جربت طلع نتيجة لشخص قرايبي وستنيت أكتر من 3 ساعات لحتى أقدر أعمل بحث على رقم الاكتتاب فقط!
وهون السؤال يلي لازم نطرحه كمهندسين ومختصين تقنيين:
هل المشكلة بالموارد (سيرفرات، شبكات، مزود خدمة)؟ ولا بآلية تصميم التطبيق وغياب الحلول الهندسية المناسبة لتحمل الضغط؟
المشكلة من منظور تقني انو:
آلاف أو ملايين الطلبات (Requests) بنفس اللحظة وعلى نفس ال Server.
تطبيق أو API واحد غير مهيأ للتعامل مع كم كبير من الطلبات أو قاعدة بيانات مركزية واحدة تتلقى كل الاستعلامات.
غياب Load Balancing فعال أو Caching Layer يقلل الحمل أو اي حلول تكون High Availability.
ونتيجة لكل المذكور بصير عنا انهيار بالخدمة وضعف بلأداء.
طيب هلئ انا نشرت لبوست مثلا بس لاحكي عن المشكلة وخلص؟؟! طبعا لأ، انا رح اقترح الحلول التالية وبتمنى تصل لأصحاب القرار بلكي بيكون في جدية بتحسين البنية التحتية التقنية يلي بتمس المواطن بشكل مباشر.
الحلول المقترحة:
1. Load Balancing فعلي:
استخدام أدوات مثل HAProxy أو NGINX لتوزيع الحمل بين عدة سيرفرات لتخفيف الضغط وتوزيع الحمل على أكثر من Server.
2. In-memory caching layer:
مثل Redis لتخزين الجلسات وادارة ال Caching مؤقتًا.
يعني لما طالب يطلب نفس النتيجة، ما تتكرر الاستعلامات على قاعدة البيانات وهاد كتير شائع وهيك حركة رح تخفف الحمل بشكل كتير كبير على قاعدة البيانات.
3. SQL Proxy / Read Replicas:
إذا الوزارة بتستخدم MySQL مثلا لتخزين ال Data فيهن يستخدموا ProxySQL لتوزيع الطلبات على أكثر من replica.
أو PostgreSQL + PgBouncer لتقليل عدد الاتصالات المباشرة ويحولوا اي عمليات ReadOnly على Server وكل عمليات ال Write, Update, Insert على سيرفر قاعدة البيانات ويلي بيكون معمله Replication على أكثر من سيرفر لنضمن انو شغلنا كلو ضمن ال High Availability ونتجنب اي انقطاع بالخدمة.
4. Queueing System:
نظام انتظار بسيط (Rate Limiting / Queue) بدل من الأخطاء الغير منطقية يلي بتطلع بالعادة مثل 404 أو رقم الاكتتاب غير موجود. هيك المستخدم يعرف أنه جار معالجة طلبك ولازم يستنى شوية.
5. Content Delivery Optimization:
من المهم جدا فصل الواجهة الأمامية (Frontend) عن الـAPI وال Backend عبر CDN أو static hosting أو يكون كل واحد فيهم على Dedicated Server خاص فيه.
بالنهاية يلي حابب احكيه انو احنا عنا بسوريا مهندسين أكفاء ومبدعين، لكن يلي منحتاجه فعلا هو تمكينهم، منحهم القرار والثقة، وإعطاؤهم فرصة لبناء أنظمة تعتمد المعايير الصحيحة، مو الحلول المؤقتة.
بتمنى من كل زملائي المهندسين والمختصيين نحكي عن هيك مواضيع، ونشارك خبرتنا لتحسين الخدمات يلي فعلاً بتهم الناس ويلي عنده حلول اضافية ياريت يسلط
الضوء عليها. عذروني طولت عليكن الحديث 
