المشكلة
وُجد TopSec لتجميع البيانات ومزامنتها وعرضها في الزمن الحقيقي دون الاتّكاء على بنية تحتية ضخمة أو حزم أثقل ممّا يحتاجه المنتج. الموجز سهل في القول، صعب في التنفيذ: إبقاء البيانات حيّة وسريعة ومتّسقة بينما تتحدّث عدّة خدمات معًا في الوقت نفسه.
أصعب قرار
رسم خطّ واضح بين ما يعيش في خلفية .NET 8 وما يُحلّ من Next.js. كشفت حالة دقيقة هذا الخطّ: مسارات /api مع وسيط next-intl كانت تنتج عمليات إعادة توجيه 307 نحو /es/api/*. صحيحة تقنيًا، مكسورة عمليًا. كانت نقاط النهاية لحظية والإحصاءات تفشل بصمت في إعدادات لغوية معيّنة.
الترقيع الذي لا يطلبه أحد هو ما يبرّر سعر المهندس: بدلًا من إصلاح قواعد إعادة التوجيه واحدة تلو الأخرى، أعدت كتابة مُطابق الوسيط ليستثني /api كلّيًا. تغيير صغير بصريًا، كبير معماريًا.
التحسين المبكر سيّئ. تجاهل الأداء من اليوم الأول أسوأ.
مبدأ عمل
كان القرار الآخر هو إبقاء PostgreSQL مصدرًا واحدًا للحقيقة. بالنسبة لهذا المنتج كان الاتّساق والقدرة على كتابة استعلامات معقّدة أثمن من أيّ سرعة يمكن انتزاعها من مخزن NoSQL. الممل لا بأس به حين يكون الممل صحيحًا.
ما كسرته
سقط الإنتاج مرّة لأنّني افترضت أنّ صورة Docker أُعيد بناؤها فعلًا. كان الكود «الجديد» يتصرّف مثل القديم تمامًا. الجاني الحقيقي كان npm ci الذي يفشل بصمت بسبب غياب package-lock، تاركًا البناء غير متّسق. قضيت ساعات في تنقيح منطق التطبيق فيما كانت المشكلة في خطّ الإنتاج.
الدرس
لا تثق بأيّ نشر حتّى تتحقّق بعينَيك من القطعة التي تعمل فعلًا. SHA الصورة، تحقّق من تجزئة الحاوية، سجّل commit البناء عند الإقلاع. أرخص دقيقة ستنفقها على الإطلاق.
النتيجة
- بنية متعدّدة الخدمات مستقرّة على VPS: خلفية، واجهة، Redis، PostgreSQL، nginx، كلّها منسّقة.
- هبوط كبير في أخطاء التوجيه والزمن الحقيقي بعد إعادة كتابة الوسيط.
- تحسّن في أزمنة الاستجابة بفضل تخزين مؤقّت موضعي وفصل واضح للمسؤوليات.
- بنية جاهزة لتنمو بوحدات جديدة دون إعادة كتابة الأساس.
- الواجهة العامّة: mkir.es. شروحات تقنية أعمق متاحة عند الطلب.