مقابلات System Design: ما يغفل عنه المهندسون في المستوى المتوسط

أغلب المهندسين يدخلون جلسة الـ system design ويبدؤون مباشرة في رسم المربعات. مربع قاعدة بيانات. مربع service. مربع cache. والـ interviewer يتفرج ويفكر: "هذا تعلّم من YouTube." مو مديح.

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

ما هي مقابلة System Design بشكل مباشر؟

مقابلة تصميم الأنظمة (System Design Interview) هي جلسة مدتها 45-60 دقيقة تُطلب فيها تصميم نظام برمجي واسع النطاق من الصفر، مثل "صمّم feed تويتر" أو "ابنِ نظام تتبع السائقين في تطبيق توصيل." الهدف من الجلسة إنك تُثبت قدرتك على التفكير في الغموض، مو مجرد ذكر المصطلحات الصح.

في المستوى المتوسط (L4-L5 عند Google، SDE-II عند Amazon)، ما المطلوب منك إعادة تصميم Kafka من الذاكرة. المطلوب تعرف متى تستخدم message queue لفصل إرسال الإشعارات عن الـ API response، وما هو الـ tradeoff بين الـ consistency والـ availability في هذا الخيار.

مقابلات الـ system design تختلف عن جولات الكود في نقطة حاسمة: ما فيه إجابة صح واحدة. الـ interviewer يقيس طريقة تفكيرك، مو يصحح اختبار. وبحسب مسح Levels.fyi لعام 2023 على أكثر من 1,200 مهندس، 68% منهم حددوا جولة الـ system design كأكثر جولة رسبوا فيها في المقابلات النهائية.

كيف يرسب المهندسون المتوسطون في هذه الجولة؟

السبب الأول مو قلة المعرفة التقنية، بل إنهم يتخطون مرحلة الـ conversation.

المهندسون الجدد ما يسألون أسئلة. يسمعون "صمّم URL shortener" ويبدؤون فوراً في رسم المخطط. المهندسون Senior يعرفون إن أول 5-7 دقائق تكون بالكامل لاستكشاف المتطلبات: لمن هذا النظام؟ ما الحجم المتوقع؟ هل نحتاج aliases مخصصة؟ هل الـ redirect يحتاج سرعة أم مجرد يشتغل؟

المهندسون المتوسطون اللي ينجحون يعاملون مرحلة توضيح المتطلبات كعمل أساسي، مو مجرد إجراء شكلي.

interviewer من مستوى L5 في Google وصف الأمر في thread على Blind عام 2024 (847 upvotes): المهندسون اللي تميزوا قضوا ضعف الوقت على المتطلبات مقارنة بالتصميم. اللي فشلوا انتقلوا للـ architecture قبل ما يسألوا سؤالاً واحداً.

والمشكلة الثانية: التصميم لحجم لا نهائي من الدقيقة الأولى. ما تحتاج Kafka ومنظومة CDN و3 طبقات caching لـ URL shortener يستقبل 1,000 redirect يومياً. المبالغة في التصميم تدل على إنك ما تقدر تقرأ المتطلبات، وهذا بالضبط ما يُفترض أن يتقنه المهندس المتوسط.

كيف يجب على المهندسين في المستوى المتوسط أن يتعاملوا مع مقابلة تصميم الأنظمة؟

مقابلة الـ system design تقيس قدرتك على التفكير في الغموض، مو قدرتك على حفظ مصطلحات الأنظمة الموزعة. النهج اللي يشتغل باستمرار: اقضِ أول 5-7 دقائق في توضيح المتطلبات، وحدد عقد الـ API قبل ما ترسم أي قاعدة بيانات، ثم ابنِ الـ flow الأساسي من البداية للنهاية قبل ما تضيف عناصر التوسع. في المستوى المتوسط (نطاق L4/L5)، المتوقع منك إنك تفرق بين النظام الذي يعتمد بشكل رئيسي على القراءة (read-heavy) وذلك الذي يعتمد على الكتابة (write-heavy)، وتصمم بناءً على الأحجام الفعلية. الـ interviewers ما يتوقعون Kafka و microservices بشكل افتراضي، هم يسمعون للخيارات المبررة. خدمة PostgreSQL بسيطة مع Redis في المقدمة تحل أغلب سيناريوهات المقابلات بشكل نظيف. المهندسون اللي ينجحون يصرّحون بالـ tradeoff بصوت عالٍ: "اخترت SQL لأن البيانات ذات علاقات ولأن حجم القراءة ما يستدعي الـ horizontal sharding بعد." هذا التحديد هو اللي يفرق بين إجابة ناجحة وإجابة عامة.

أي نهج يشتغل فعلياً مع مرشحي المستوى المتوسط؟

فيه نهج عملي من 5 خطوات يستخدمه المرشحون اللي ينجحون باستمرار في هذه الجولة:

1. وضّح الـ scope. اسأل 4-6 أسئلة محددة: الحجم المتوقع، مدة الاحتفاظ بالبيانات، متطلبات الـ latency، الموقع الجغرافي للمستخدمين، نسبة القراءة للكتابة.
2. حدد عقد الـ API. قبل أي مخطط، اكتب الـ endpoints أو الـ interfaces الرئيسية. هذا يوضح ما يفعله النظام فعلاً.
3. ارسم الـ data model. ما هي الكيانات الأساسية؟ ما الذي يُخزَّن، ولمدة كم، وبأي شكل؟
4. صمّم الـ core flow أولاً. ابنِ المسار الأساسي من البداية للنهاية قبل إضافة عناصر المرونة.
5. أضف التوسع بعد كل هذا. فقط الآن تُضيف الـ caches والـ queues والـ sharding والـ replication، مع ذكر الـ tradeoffs لكل خيار.

هذا الترتيب مهم. أغلب المرشحين يعكسون الخطوات 2-3 مع الخطوة 1، فينتهون بتصميم مشكلة ما فهموها بشكل كامل.

أكبر قرار تصميمي تتخذه في أي مقابلة system design هو ما تختار عدم تضمينه في التصميم، ولماذا.

IntervYou تتبع هذا النهج بالضبط في جلسات الـ mock design، والـ coach يتوقف عند نفس النقاط اللي يتوقف عندها الـ interviewer الحقيقي. الفرق عن مشاهدة YouTube: تُجبر على ممارسة العادة، مو مجرد التعرف عليها.

مثال عملي 1: تصميم URL Shortener

إليك مثالاً على إجابة مقابلة تصميم ناجحة في المستوى المتوسط، بصيغة حوار.

Interviewer: صمّم URL shortener مشابه لـ bit.ly.

المرشح: بعض الأسئلة قبل ما أبدأ. ما الحجم اليومي المتوقع؟ نتكلم عن آلاف الروابط أم ملايين الـ redirects يومياً؟

Interviewer: لنقل 100 مليون redirect يومياً، و1 مليون رابط جديد يومياً.

المرشح: طيب. هل يحتاج المستخدمون تخصيص الـ short codes، أم الإنشاء العشوائي كافٍ؟ وهل نحتاج analytics مثل عدد النقرات لكل رابط؟

Interviewer: لا aliases مخصصة الآن. الـ analytics خارج الـ scope.

المرشح: ممتاز. إذن الـ API الأساسي عمليتان: POST /shorten لإنشاء الرابط المختصر، وGET /{code} للـ redirect. الـ write path بسيطة: نولّد code مكوناً من 6-7 أحرف، نخزّن الـ mapping، ونعيد الرابط المختصر. الـ read path هي المهمة عند 100 مليون redirect يومياً.

في هذا الحجم، الـ reads أكثر من الـ writes بـ 100 مرة. سأضع طبقة cache مثل Redis أو Memcached أمام قاعدة البيانات للبحث في الـ redirect. نسبة الـ cache hit ستكون عالية لأن توزيع الروابط يتبع عادةً قانون الـ power-law: 20% من الروابط تولّد قرابة 80% من الـ traffic. قاعدة البيانات تصلح SQL أو NoSQL في هذه الحالة، الـ schema بسيطة جداً. سأختار SQL للتدقيق ما لم نحتج horizontal sharding.

ما لم يفعله المرشح: لم يذكر Kafka أو CDNs أو microservices. لم يكن أي منها ضرورياً. البدء بعقد الـ API ونسبة القراءة للكتابة وضّح ما يتطلبه الحجم فعلاً.

مثال عملي 2: تصميم نظام الإشعارات

Interviewer: صمّم نظام إشعارات لتطبيق جوال، push notifications وإيميلات.

المرشح: بعض الأسئلة أولاً. ما نوع الإشعارات: معاملاتية فقط أم تسويقية أيضاً؟ وما الحجم؟

Interviewer: معاملاتية: تحديثات الطلبات، تأكيدات الدفع. حتى 5 ملايين يومياً.

المرشح: وما متطلبات الـ latency؟ هل تأكيد الطلب يحتاج يصل في أقل من ثانية، أم بضع ثوانٍ مقبول؟

Interviewer: بضع ثوانٍ مناسبة لأغلبها؛ أقل من 10 ثوانٍ لتأكيدات الدفع.

المرشح: إذن سأفصل إنشاء الإشعار عن إرساله. الـ API الذي ينشئ الإشعار يجب أن يكون سريعاً: يكتب سجلاً في queue ويعود فوراً. consumer منفصل يتولى الإرسال عبر استدعاء خدمات push من Apple/Google أو مزود إيميل مثل SendGrid. هذا الفصل يعني إن ارتفاع الطلبات ما يعطّل الـ payment API.

للإرسال، سأجعل worker pools منفصلة لكل channel. الـ push والإيميل لهما منطق retry مختلف جداً: الإيميلات تتحمل الانتظار دقائق، الـ push notifications لها نوافذ أضيق.

فصل إنشاء الإشعارات عن إرسالها عند حد الـ queue هو قرار التصميم الحاسم هنا، وتحتاج تقوله بصوت عالٍ وتشرح السبب، مو مجرد ترسم السهم.

مثال عملي 3: تصميم نظام تتبع مواقع السائقين

Interviewer: صمّم مكوّن تتبع المواقع لتطبيق مشاركة رحلات مثل Careem.

المرشح: من يرسل تحديثات الموقع، ومن يقرأها؟ السائقون يرسلون تحديثات GPS كل بضع ثوانٍ، والراكبون يستعلمون في الوقت الفعلي؟

Interviewer: نعم. السائقون يحدّثون كل 3-5 ثوانٍ. الراكبون يستطلعون أو يستقبلون الموقع مباشرة.

المرشح: حجم الأسطول: 10,000 سائق متزامن أم أكثر؟

Interviewer: 500,000 سائق في ذروة التشغيل.

المرشح: عند 500,000 سائق يحدّثون كل 4 ثوانٍ، هذا تقريباً 125,000 كتابة في الثانية. قواعد بيانات SQL العادية لا تتحمل هذا المعدل بدون تصميم متخصص. سأستخدم Redis مع أوامر الـ geospatial، يعني GEOADD وGEOPOS وGEORADIUS، وهي مصممة لهذا بالضبط. للراكبين الذين يقرؤون موقع السائق، سأدفع التحديثات عبر WebSocket أو Server-Sent Events بدلاً من الـ polling. الـ polling من مليون راكب كل 3 ثوانٍ يولّد حمولة هائلة. طبقة pub/sub توجّه تحديثات كل سائق لأي راكب مشترك في معرّف ذلك السائق.

الجزء الصعب هنا مو حجم الكتابة، بل توجيه التحديث الصحيح للراكب الصحيح، وهذه مشكلة إدارة اشتراكات وليست مشكلة تخزين.

ما أكثر الأخطاء التي يرتكبها المهندسون في المستوى المتوسط؟

1. تصميم الـ schema قبل الـ API. إذا ما تعرف ما يجب أن يفعله النظام، ما تعرف ما يجب أن يخزنه.

2. التعامل مع التوسع كشيء متجانس. مو كل مكوّن يحتاج يتوسع بنفس الطريقة. في الـ URL shortener، الـ reads أكثر من الـ writes بـ 100 مرة. في نظام الإشعارات، الـ writes متقطعة. طابق قرارات التوسع مع الـ bottleneck الحقيقي، مو مع أسوأ حالة متخيلة.

3. تخطي توضيح الـ tradeoff. قول "سأستخدم PostgreSQL" بدون شرح السبب ما يترك للـ interviewer شيئاً يقيّمه. هو يعرف إن PostgreSQL موجودة. يريد يسمع: "اخترت Postgres لأن البيانات ذات علاقات والفريق يملك خبرة SQL وحجم 100K QPS للقراءة ضمن نطاق cluster منظم بشكل صحيح."

4. نفاد الوقت قبل التطرق لحالات الفشل. في مستوى L4-L5، الـ interviewers يتوقعون منك ذكر سيناريو فشل واحد على الأقل: ماذا يحدث إذا انهار الـ cache، أو تعطل worker في الـ queue؟ ما تحتاج تحله بالكامل، تحتاج فقط تُظهر إنك فكرت فيه.

5. قبول scope creep أثناء التصميم. إذا قال الـ interviewer "لنتجاهل الـ analytics الآن"، لا تُعيدها خلسةً في مرحلة التصميم. البقاء في الـ scope إشارة واضحة: تُظهر قدرتك على إدارة المتطلبات في سياق هندسي حقيقي.

أي framework لتصميم الأنظمة يجب أن تستخدم؟

عدة أطر موجودة لتنظيم هذه المقابلة. هنا مقارنة أبرزها:

لأغلب مرشحي المستوى المتوسط، Requirements-first هو الخيار الصح كنقطة انطلاق، لأنه يعكس طريقة تفكير المهندسين الفعلية عند بناء الأنظمة، وهذا بالضبط ما يقيسه الـ interviewer.

إذا كنت تعاني من التوقيت أو العمق في مقابلات الـ design، المشكلة في الغالب مو المعرفة، بل إنك ما مررت بتجربة أحد يوقفك في منتصف الجلسة ويسألك "ليش اتخذت هذا القرار؟" مارس هذا النمط مع IntervYou قبل ما تحتاجه في مقابلة حقيقية.

مقابلة الـ system design هي الجولة الوحيدة التي يهم فيها الـ communication والـ structure أكثر من المعرفة الخام. أغلب المهندسين المتوسطين لديهم المعرفة التقنية الكافية، لكن اللي يرسبون يتخطون مرحلة المتطلبات، ويبالغون في التصميم من البداية، وما يقولون كلمة "tradeoff" بصوت عالٍ.

Start a free mock →

مقالات ذات صلة

• كيف تستعد لمقابلة مهندس برمجيات في Google
• مقابلة مهندس البرمجيات في Apple: شرح كامل للعملية
• كيف تستعد لمقابلة مهندس البرمجيات في 4 أسابيع