This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.
خلال 15 ثانية فقط، قفز معدل استهلاك المعالج إلى 95%، وتصاعد استهلاك الذاكرة بشكل حاد، فيما توقفت خدمة الذكاء الاصطناعي (Gemini AI)—المسؤولة عن التحليل الأمني الفوري—عن الاستجابة تماماً. كان من شأن هذا الانهيار، لو حدث أثناء التقييم الفعلي أمام الهيئة الوطنية للأمن السيبراني (NCA)، أن ينهي المشروع كاملاً. لم أكن أعلم حينها أن تلك الليلة ستعيد تشكيل رؤيتي المعمارية لبناء البرمجيات بشكل جذري.
كانت البنية الهندسية للنظام تبدو واعدة على الورق: واجهة مستخدم مبنية بـ React، وخلفية برمجة بـ Node.js/Express، مع إطار Kubernetes لإدارة الحاويات وعزلها، ونظام Vault لتشفير مفاتيح HMAC، إضافة إلى ربط مستمر بحزمة Gemini SDK لتحليل السجلات الأمنية بشكل لحظي. وبصفتها منصة سيادية (PaaS)، فإن أي خلل في المعالجة قد يؤدي لتسريب بيانات حكومية حساسة.
لم يكمن الخلل في الأدوات ذاتها، بل في التسلسل المتزامن لعمليات الطلب (Request Pipeline)؛ إذ كان كل طلب يمر بسلسلة خطية مجهدة: التحقق من مفتاح HMAC عبر Vault، ثم استعلام بيانات المستأجر من PostgreSQL، وتسجيل النشاط في Redis، وانتظار معالجة Gemini AI للسجلات، قبل إرسال الاستجابة النهائية للمستخدم. في بيئة التطوير المحلية، كانت العملية تستغرق نحو 200 مللي ثانية، وهو معدل ممتاز، لكن تحت ضغط آلاف الطلبات في الثانية، تحول هذا التأخير التراكمي إلى اختناق حاد في المعالجة (Throughput Bottleneck)، مما أدى لتكدس الطلبات وتجميد الخيوط البرمجية أثناء انتظار رد الذكاء الاصطناعي.
بعد ساعة من فحص السجلات وتتبع الأداء، اتضح الخلل المعماري الأساسي: الاعتماد على الحظر المتزامن (Synchronous Blocking)، حيث يظل الخادم في حالة انتظار لاستجابة نموذج الذكاء الاصطناعي قبل إتمام الطلب، وهو نمط تصميمي غير صالح للأنظمة ذات الأحمال العالية.
خلال 36 ساعة من العمل المتواصل، أعدت هيكلة النظام عبر ثلاث خطوات رئيسية:
في تمام الساعة الخامسة صباحاً، أعدت تشغيل المنظومة وأجريت المحاكاة من جديد. أظهرت لوحة المراقبة استجابة مختلفة تماماً؛ ارتفع المؤشر مؤقتاً لكنه استقر بسرعة، حيث فعّلت أداة HPA في Kubernetes التوسع الأفقي للأحمال بنجاح. خلال 2.1 ثانية فقط، امتص النظام الصدمة واستقر، وبدأت سجلات Gemini AI تُعالج في الخلفية بشكل دوري كل 5 ثوانٍ دون أي أثر على سرعة الواجهة.
أثبتت هذه التجربة أن الأداء العالي في الأنظمة السيادية ليس مجرد تحسين تحسيني، بل هو خط الدفاع التشغيلي الأول. صرت أطرح عند كتابة أي وحدة برمجية أسئلة تتجاوز صحة الوظيفة المباشرة لتشمل: كيف ومتى تُدار أولويات التنفيذ تحت الضغط العالي؟ وعندما ترى منصة PaaS تستجيب في أقل من 50 مللي ثانية، فاعلم أن وراءها معمارية جرى صقلها عبر التعامل المباشر مع اختناقات الـ Event Loop وآليات التخزين المؤقت.
هل واجهتم تحديات معمارية مماثلة في التعامل مع اختناقات الأداء أو استدعاءات API أثناء ذروة الاستخدام؟ أرحب بمشاركة تجاربكم التقنية في هذا الصدد.