كيف نُصمم بنية قابلة للتوسع

التوسّع ليس لحظةً تأتي فجأة، بل سلسلة قرارات تُتّخذ مبكرًا. أكثر المشاكل التي رأيناها في الأنظمة المتعثّرة لم تكن في الحِمل، بل في افتراضاتٍ بُنيت يوم كان النظام صغيرًا.

ابدأ من البيانات

نموذج البيانات هو القرار الأصعب في التراجع عنه. قبل كتابة أول واجهة برمجية، نسأل: كيف ستنمو هذه الجداول؟ وأين ستكون نقاط الاختناق حين تتضاعف الأرقام عشر مرات؟

الحالة عدوّ التوسّع

كل حالةٍ نحتفظ بها في الذاكرة هي قيدٌ على قدرتنا على التوزيع. نُصمم الخدمات لتكون عديمة الحالة قدر الإمكان، فتصبح الزيادة الأفقية مسألة نسخٍ لا إعادة بناء.

قِس قبل أن تُحسّن

التحسين المبكر يُهدر الوقت على مشاكل لا وجود لها. نُضيف القياس من اليوم الأول، ثم نُحسّن ما تُثبت الأرقام أنه يستحق — لا ما نظنّه بطيئًا.

البنية الجيدة لا تجعل التوسّع سهلًا، بل تجعله مملًّا. وهذا أفضل وصفٍ نطمح إليه.