مقابلاتي لتصميم النظم كانت كارثة: كيف أنقذني هذا الإطار المنهجي من جحيم الرفض؟

يا جماعة، خليني أحكيلكم قصة صارت معي قبل كم سنة، قصة بتوجع القلب شوي بس نهايتها سعيدة. كنت مقدم على وظيفة في شركة من شركات الأحلام، شركة كبيرة والكل بحلم يشتغل فيها. بعد ما عديت المراحل الأولى من المقابلات، وصلت للمرحلة الحاسمة: مقابلة تصميم النظم (System Design Interview).

دخلت المقابلة وأنا كلي ثقة. أنا أبو عمر، مبرمج إلي سنين في السوق وبعرف شغلي كويس. سألني المقابل: “يا أبو عمر، كيف ممكن تصمم نظام زي تويتر؟”. لمعت عيوني، وقلت في نفسي: “بسيطة!”. وبدأت مباشرة بالحل: “أول إشي بنجيب Kafka عشان الـ real-time feed، وبنستخدم Microservices وبنقسمهم لخدمة للمستخدمين وخدمة للتغريدات وخدمة للـ timeline، وبنحط Kubernetes عشان يعمل orchestrate للحاويات، وقاعدة البيانات لازم تكون NoSQL زي Cassandra عشان تتحمل الكتابة الكثيفة…”.

وأنا بحكي وبحكي، لاحظت إنه المقابل بهز براسه بهدوء، بس نظراته كانت فاضية. حسيت حالي زي اللي بركض في مكاني. بعد ما خلصت وصلة الحكي الطويلة، سألني سؤال بسيط قتلني: “طيب يا أبو عمر، كم مستخدم بتتوقع يستخدم النظام؟ وشو أهم ميزة لازم نركز عليها في البداية؟”.

سكتت… ما كنت محضر جواب. أنا قفزت مباشرة للحلول والتقنيات اللامعة ونسيت أهم إشي: أفهم المشكلة نفسها. كانت مقابلتي فوضى عارمة، مجرد سرد لأسماء تقنيات بدون أي هيكل أو منطق. طبعاً، بعد يومين وصلني إيميل الرفض اللطيف. هاي التجربة، مع كم تجربة فاشلة زيها، كانت زي الكف اللي صحاني. أدركت إنه المعرفة التقنية لحالها ما بتكفي، لازم يكون عندك “منهجية”.

من الفوضى إلى المنهجية: نقطة التحول

بعد سلسلة من الإخفاقات، قعدت مع حالي وفكرت: “شو الغلط اللي بعمله؟”. المشكلة ما كانت في معرفتي بالـ Caching أو الـ Load Balancers أو قواعد البيانات. المشكلة كانت في “كيف” بقدم هاي المعرفة. المقابل ما بده يسمع موسوعة تقنية، بده يشوف كيف بتفكر، كيف بتحلل المشكلة، وكيف بتتعاون عشان توصل لحل. بده يشوف مهندس، مش بياع تقنيات.

مقابلة تصميم النظم مش اختبار ذاكرة، هي محاكاة لجلسة عمل حقيقية بين مهندسين. هدفك مش تعطي الجواب “الصح” من أول دقيقة، هدفك هو إنك تقود نقاش مثمر وتوضح طريقة تفكيرك المنظمة. ومن هنا، بدأت أبحث وأتعلم عن “أطر العمل” (Frameworks) المخصصة لهيك مقابلات. واليوم، بدي أشارككم الإطار اللي غيّر مسيرتي المهنية وأنقذني من جحيم الرفض.

الإطار المنهجي الذي أنقذني: خطوة بخطوة

هذا الإطار مش قانون مقدس، هو مجرد خريطة طريق بتساعدك تنظم أفكارك وتضمن إنك تغطي كل الجوانب المهمة. خلينا نمشي فيه خطوة بخطوة.

الخطوة 1: الاستيعاب وجمع المتطلبات (Clarification & Requirements Gathering)

هاي أهم خطوة، وإياك ثم إياك تتجاوزها. قبل ما تكتب أي شي على اللوح أو تحكي أي اسم تقنية، لازم تفهم المشكلة 100%. كن فضوليًا، مش فهيمًا. ابدأ بطرح الأسئلة الذكية:

• المتطلبات الوظيفية (Functional Requirements):
  • ما هي الميزات الأساسية للنظام؟ (مثال: في نظام تويتر، هل المطلوب هو نشر تغريدة، رؤية الـ timeline، متابعة مستخدمين؟)
  • من هم المستخدمون؟ (مثال: هل هم مستخدمون عاديون، أم مسؤولون عن النظام؟)
  • هل هناك ميزات ثانوية يجب أن نأخذها في الحسبان؟ (مثال: الرسائل المباشرة، البحث، الـ trending topics)
• المتطلبات غير الوظيفية (Non-Functional Requirements):
  • التوافرية (Availability): هل النظام لازم يكون متاح 99.999% من الوقت؟ هل يمكن أن يتحمل بعض التوقف؟
  • قابلية التوسع (Scalability): كم عدد المستخدمين المتوقعين؟ (10 آلاف؟ 10 ملايين؟) كم عدد الطلبات في الثانية (RPS)؟
  • زمن الاستجابة (Latency): ما هو زمن الاستجابة المقبول لتحميل الـ timeline مثلاً؟ (100ms؟ 500ms؟)
  • الاتساق (Consistency): هل يجب أن تظهر التغريدة الجديدة فوراً لكل المتابعين (Strong Consistency) أم يمكن أن يكون هناك تأخير بسيط (Eventual Consistency)؟

نصيحة أبو عمر: اكتب المتطلبات هاي على زاوية اللوح (Whiteboard). هاي الحركة بتورجي للمقابل إنك منظم، وبتساعدك ترجعلها خلال المقابلة عشان تتأكد إن تصميمك بحققها.

الخطوة 2: تقديرات أولية (Back-of-the-Envelope Estimation)

هاي الخطوة بتفصل المهندس الخبير عن المبتدئ. قبل ما ترسم أي مربعات، حاول تعمل شوية حسابات بسيطة عشان تعرف حجم النظام اللي بتتعامل معه. هاي الحسابات بتساعدك تختار التقنيات المناسبة لاحقاً.

• تقدير حجم التخزين (Storage Estimation): لو عنا مليار مستخدم، وكل مستخدم بيكتب تغريدة يومياً، والتغريدة حجمها 1KB… كم مساحة بنحتاج لمدة 5 سنوات؟
• تقدير حجم التبادل (Bandwidth Estimation): كم عدد طلبات القراءة مقابل الكتابة؟ (Read/Write Ratio). مثلاً في تويتر، القراءة أكثر بكثير من الكتابة. هذا بيعطيك فكرة عن أهمية الـ Caching.
• تقدير عدد الطلبات في الثانية (QPS/RPS): لو عنا 500 مليون مستخدم نشط يومياً، كم طلب ممكن يوصلنا في الثانية الواحدة في أوقات الذروة؟

هاي الأرقام مش لازم تكون دقيقة 100%، الهدف هو إظهار قدرتك على التفكير بحجم المشكلة (Scale).

الخطوة 3: تصميم الواجهات البرمجية (API Design)

قبل ما تخوض في تفاصيل قواعد البيانات والخوادم، فكر كيف ستتفاعل أجزاء النظام مع بعضها البعض أو كيف سيتفاعل العميل (الموبايل أو الويب) مع الخادم. حدد الـ Endpoints الرئيسية.

مثلاً، لتصميم خدمة تقصير روابط (URL Shortener):

// لإنشاء رابط قصير جديد
POST /api/v1/url
Request Body: { "long_url": "https://..." }
Response: { "short_url": "https://short.ly/xyz123" }

// لإعادة التوجيه من الرابط القصير إلى الطويل
GET /{short_code}
Response: 301 Redirect to long_url

تحديد الـ API من البداية يساعد على توضيح حدود كل خدمة ويبين فهمك لأساسيات بناء الأنظمة الموزعة.

الخطوة 4: تصميم قاعدة البيانات (Database Design)

هنا يبدأ الجد. بناءً على المتطلبات والتقديرات، لازم تختار نوع قاعدة البيانات وتصمم الـ Schema بشكل مبدئي.

• SQL vs. NoSQL: هذا هو النقاش الأزلي. لا تقل “سأستخدم NoSQL لأنها أحدث”. برر اختيارك.
  • استخدم SQL (مثل PostgreSQL, MySQL): إذا كنت تحتاج لـ ACID transactions (مثل الأنظمة المالية)، أو إذا كانت بياناتك منظمة جداً والعلاقات بينها معقدة.
  • استخدم NoSQL (مثل Cassandra, MongoDB, DynamoDB): إذا كنت تحتاج لقابلية توسع أفقية هائلة، أو بياناتك غير منظمة (semi-structured)، أو تحتاج لسرعة عالية في الكتابة/القراءة لحالات استخدام معينة.
• تصميم الـ Schema: ارسم الجداول الأساسية والأعمدة الرئيسية. مثلاً في نظام تويتر، ممكن يكون عندك جدول `Users` وجدول `Tweets` وجدول `Follows`. فكر في العلاقات بينها (One-to-Many, Many-to-Many).

الخطوة 5: التصميم عالي المستوى (High-Level Design)

الآن، ارسم الصورة الكبيرة. استخدم مربعات وأسهم بسيطة لتوضح المكونات الرئيسية وكيفية تواصلها.

تصميمك المبدئي ممكن يكون بسيط جداً:

Client -> Load Balancer -> Web Servers -> Database

هذا هو الهيكل العظمي للنظام. من هنا، ستبدأ بإضافة اللحم عليه في الخطوات التالية. لا تقفز للـ Microservices والـ Message Queues من البداية إلا إذا كانت المشكلة تتطلب ذلك بوضوح. ابدأ بسيطًا ثم قم بالتطوير.

الخطوة 6: الغوص في التفاصيل وتحسين التصميم (Deep Dive & Scaling)

هنا سيقوم المقابل بتوجيهك نحو نقاط الضعف في تصميمك (Bottlenecks) ليسألك كيف ستحلها. كن مستعداً لمناقشة المواضيع التالية:

• Load Balancing: كيف ستوزع الحمل على الخوادم؟ (Round Robin, Least Connections, etc.)
• Caching: أين ستضع الكاش؟ (Client-side, CDN, Server-side). ما هي البيانات التي ستخزنها في الكاش؟ ما هي سياسة إخلاء الكاش (Cache Eviction Policy)؟ (LRU, LFU, FIFO).
• Database Scaling: كيف ستتعامل مع الضغط على قاعدة البيانات؟
  • Replication: استخدام (Master-Slave) لتحسين أداء القراءة.
  • Sharding: تقسيم البيانات على عدة قواعد بيانات للتعامل مع الحجم الهائل.
• Asynchronous Processing: استخدام طوابير الرسائل (Message Queues) مثل RabbitMQ أو Kafka لفصل المهام الطويلة عن الطلب الرئيسي، مثل إرسال الإشعارات أو معالجة الفيديوهات.
• Content Delivery Network (CDN): لتقديم المحتوى الثابت (صور، فيديوهات، CSS) بسرعة للمستخدمين حول العالم.

الخطوة 7: تحديد عنق الزجاجة والتحسينات (Bottlenecks & Trade-offs)

في نهاية المقابلة، من الرائع أن تراجع تصميمك وتناقش نقاط الضعف المحتملة والـ Trade-offs التي قمت بها. هذا يظهر نضجك كمهندس.

• “تصميمي الحالي يركز على الـ Availability ولكنه يضحي ببعض الـ Consistency (Eventual Consistency). هذا مناسب لـ timeline تويتر ولكنه غير مناسب لنظام بنكي.”
• “عنق الزجاجة القادم قد يكون في خدمة الـ timeline generation، ويمكننا تحسينها عن طريق عمل pre-computation للـ timelines وتخزينها في كاش مثل Redis.”
• “إذا زاد عدد عمليات الكتابة بشكل كبير، قد نواجه مشكلة في الـ Master database، وقد نحتاج للانتقال إلى نظام Multi-Master أو قاعدة بيانات NoSQL تدعم الكتابة على نطاق واسع.”

نصائح أبو عمر الذهبية: خلاصة خبرة السنين

• فكر بصوت عالٍ (Think Aloud): المقابل لا يقرأ الأفكار. اشرح كل خطوة تقوم بها، وكل قرار تتخذه، ولماذا. حتى لو كنت تفكر في خيارين، قل “أنا أفكر بين X و Y. سأختار X لهذا السبب…”.
• قد أنت الحوار (Drive the Conversation): لا تنتظر من المقابل أن يسألك كل سؤال. بعد كل خطوة، قل “الآن بعد أن حددنا المتطلبات، الخطوة المنطقية التالية هي عمل تقديرات أولية…” أو “هل هناك جانب معين في هذا التصميم تود أن نتعمق فيه أكثر؟”.
• استخدم اللوح بفعالية: اللوح هو صديقك. ارسم، امسح، أعد الرسم. اجعل اللوح يعكس عملية تفكيرك المتطورة.
• تذكر أنها محادثة: تعامل مع المقابل كأنه زميلك في العمل. اطلب رأيه، ناقشه، ولا تخف من قول “هذه نقطة جيدة، لم أفكر بها”.
• اعرف الـ Trade-offs: لا يوجد حل مثالي في تصميم النظم. كل قرار له مزايا وعيوب. سر النجاح هو معرفة هذه المقايضات وتبرير اختياراتك بناءً عليها.

الخلاصة: من مرشح مرتبك إلى مهندس واثق ✅

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

مقابلة تصميم النظم ليست جحيماً، هي فرصة لتظهر أفضل ما لديك: ليس فقط ما تعرفه من تقنيات، بل كيف تفكر كمهندس حقيقي. تدرب على هذا الإطار، طبقه على مشاكل تصميم مختلفة (تصميم Instagram, Uber, Netflix, …)، وفي المقابلة القادمة، ستدخل وأنت تشعر بالثقة والسيطرة. بالتوفيق للجميع!