منهجية التصميم
منهجية لأي سؤال «صمّم نظام X»
«صمّم تويتر». ترتجف معدتك. ليس لأن السؤال صعب — بل لأنه بلا شكل. هذا الدرس يعطي السؤال بلا الشكل شكلاً: أربع خطوات، هي نفسها دائماً، تحوّل الذعر إلى خطة.
- وضّح المتطلبات. اسأل من يستخدمه، وماذا يفعلون، وكم عددهم. حدّد النطاق بجرأة — تصميم «تويتر» يعني اختيار ميزتين أو ثلاث، لا أربعين. اختم بقائمتين: متطلبات وظيفية (ماذا يفعل) وغير وظيفية (ما مدى السرعة والحجم والتوافر).
- قدّر. نفّذ حسابات ظرف الورقة: QPS والتخزين وسعة النقل. هذه الأرقام تقرر كل ما بعدها — هل تكفي قاعدة بيانات واحدة أم تحتاج shards، وهل الـcache رفاهية أم ضرورة.
- ارسم التصميم عالي المستوى. ارسم الصناديق والأسهم التي يتفق عليها الطرفان: العميل، load balancer، خوادم web، قاعدة البيانات، الـcache، الطابور. انطق وظيفة كل صندوق بصوت عالٍ وأنت ترسمه — هذه الخريطة المشتركة لبقية النقاش.
- تعمّق. اختر المكوّن أو المكوّنين اللذين تسكن فيهما الصعوبة الحقيقية وتعمّق فيهما: المخطط، الخوارزمية، أنماط الفشل. دافع عن كل اختيار كمقايضة — ما الذي كسبته، وما الذي تخلّيت عنه وأنت تدري.
مهندسان ممتازان سيصممان النظام نفسه بطريقتين مختلفتين — ويمكن أن يكون كلاهما محقاً، لأن كل تصميم هو حزمة مقايضات دُافع عنها جيداً. الاتساق مقابل زمن الاستجابة، البساطة مقابل التوسع، البناء مقابل الشراء. وفكرة CAP هي المثال الشهير: أثناء انقسام الشبكة (partition)، يجب على النظام الموزّع أن يختار بين الاتساق (يرفض الإجابة حتى يتأكد) والتوافر (يجيب بما لديه، ربما ببيانات قديمة). لا يمكنك الحصول على كليهما في تلك اللحظة — يمكنك فقط أن تختار، وأن تشرح السبب.
التصميم مجرد ذريعة؛ الحديث عن المقايضات هو الهدف. لا أحد يقيّم صناديقك — الكل يصغي إلى ما إذا كنت تعرف ثمن كل صندوق.
في كل خطوة، تُفحص مهارة مختلفة تحت المجهر. الخطوة 1: هل تحدّد النطاق أم تغوص أعمى — البدء بالرسم قبل السؤال علامة حمراء فورية. الخطوة 2: هل تقود أرقامك القرارات — التقديرات التي لا تغيّر أي خيار مجرد زخرفة. الخطوة 3: هل تحصل على اتفاق قبل التعمق — الرسم عالي المستوى عقد، والمقيّمون يراقبون هل تفاوض عليه. الخطوة 4: هل تدافع عن المقايضات أم تردّد أسماء الأدوات — ذكر تقنية لا يساوي شيئاً أمام قول ما ثمنها ولماذا تدفعه.
القفز إلى الأدوات هو ما يفضح المبتدئ: يقول «Kafka» قبل أن يقول ما المشكلة التي تحلها، و«Kubernetes» قبل أن يعرف الحمل. سمِّ المشكلة أولاً — فك الارتباط، امتصاص الارتفاعات، إعادة المحاولة — ثم دع الأداة تستحق مكانها. الأداة التي تبحث عن مشكلة هي تعقيد يحمل شعاراً.
لكل خطوة طريقتها الخاصة في الفشل. الخطوة 1: تخطّي التوضيح — تصمّم لمنتج خاطئ ولا ينقذك بعدها أي ذكاء. الخطوة 2: تقدير بلا عواقب — تحسب 11,600 قراءة/ثانية ثم تبني كأنك لم تحسب شيئاً. الخطوة 3: رسم صناديق لم يتفق عليها أحد — تحل نسختك أنت من المشكلة، لا نسختهم. الخطوة 4: التعمق في المكوّن السهل بدل الصعب — تتقن مخطط قاعدة البيانات بينما يبقى ترتيب الـfeed، الصعوبة الحقيقية، صندوقاً رمادياً.
طُلب منك «تصميم تطبيق محادثة». ما أول ثلاث خطوات تتخذها قبل رسم أي صندوق؟ (اسأل من المستخدمون وكم عددهم، اختر ميزتين ضمن النطاق — مثلاً الرسائل الثنائية وإيصالات التسليم — ثم قدّر QPS والتخزين. عندها فقط تظهر الصناديق.)
كل سؤال تصميم هو نفس الخطوات الأربع: وضّح المتطلبات، قدّر الأرقام، ارسم الصناديق، تعمّق في الأجزاء الصعبة. وتذكّر ما يُطلب منك حقاً: ليس التصميم الصحيح، بل مقايضات دُافع عنها جيداً.
اختر نظاماً تستخدمه يومياً — تطبيق بنكك، تطبيق توصيل طعام، لوحة تحكم شركتك — ونفّذ عليه الخطوتين 1 و2 في دفتر: اكتب المتطلبات الوظيفية وغير الوظيفية، ثم قدّر QPS والتخزين. عشر دقائق، دون رسم أي صندوق.
منهجية التصميم