مشاكل التصميم الكاملة واستراتيجية المقابلة

تجمع هذه الوحدة الأخيرة كل شيء معاً. نمر عبر ثلاث مشاكل تصميم أنظمة كاملة — YouTube وUber وGoogle Docs — مع تطبيق إطار RESHADED ومهارات التقدير والأنماط المعمارية من الوحدات السابقة. ثم نغطي أنماط الأمان وأسئلة عصر الذكاء الاصطناعي، ونختتم بإتقان التواصل في المقابلات.

مشكلة التصميم 1: صمم YouTube

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

المتطلبات

ملاحظة عن الأرقام أدناه، وعن كل رقم حجم في هذه الوحدة: اذكرها بوصفها افتراضات اخترتها، لا حقائق حفظتها. الأرقام المنشورة الحقيقية لهذه المنتجات تتغير باستمرار، والمحاور الذي يصادف معرفته بالرقم الحالي سيُخرج تقديرك عن مساره في جدال حوله. جملة «لنفترض ملياري مستخدم نشط شهريًا و500 ساعة رفع في الدقيقة — هل يوافق هذا ما في ذهنك؟» افتتاحية أقوى من إحصائية خاطئة تُقال بثقة، وهي تدعو المحاور لأن يعطيك القيد الذي يريدك أن تصمم له فعلًا.

النوع	المتطلب
وظيفي	رفع مقاطع الفيديو، بث المقاطع، البحث عن المقاطع، عرض التوصيات
غير وظيفي	زمن تشغيل منخفض (<200ms للبدء)، توفر عالي (99.99%)، وصول عالمي
الحجم المفترض	~2 مليار مستخدم شهري نشط، ~500 ساعة فيديو تُرفع كل دقيقة، ~1 مليار ساعة مشاهدة يومياً

البنية عالية المستوى

قرارات التصميم الرئيسية

ترميز الفيديو: حوّل مقاطع الفيديو المرفوعة إلى دقات متعددة (240p، 480p، 720p، 1080p، 4K) وبرامج ترميز (H.264، VP9، AV1). استخدم البث بمعدل بت تكيفي — يبدّل العميل الجودة بناءً على ظروف الشبكة. HLS (Apple) وDASH (معيار مفتوح) هما البروتوكولان المهيمنان.

استراتيجية CDN: خزّن مقاطع الفيديو الشائعة في مواقع الحافة. استخدم بنية متدرجة: حافة → إقليمي → أصل. تنطبق قاعدة 80/20 — تقريباً 20% من المقاطع تمثل 80% من المشاهدات. سخّن المحتوى الشائع مسبقاً في الحافة.

عد المشاهدات: الاتساق النهائي مقبول. استخدم Kafka لتخزين أحداث المشاهدة مؤقتاً، جمّع بالدفعات (كل بضع دقائق)، واكتب إلى خدمة العد. للعد التقريبي الفوري، استخدم عداداً احتمالياً (HyperLogLog للمشاهدين الفريدين).

خلاصة التوصية: التصفية التعاونية (المستخدمون الذين شاهدوا X شاهدوا أيضاً Y) مدمجة مع ميزات المحتوى (بيانات الفيديو الوصفية، الفئات). احسب التوصيات مسبقاً دون اتصال، وقدمها من طبقة ذاكرة مؤقتة.

مشكلة التصميم 2: صمم Uber

مشاركة الركوب تختبر الأنظمة الجغرافية المكانية والمطابقة الفورية والتسعير الديناميكي — أنماط نادراً ما تُغطى في دورات أخرى.

المتطلبات

النوع	المتطلب
وظيفي	طلب رحلات، مطابقة مع سائقين، تتبع الرحلات فورياً، حساب الأجرة، تسعير الذروة
غير وظيفي	مطابقة خلال 30 ثانية، تحديث الموقع كل 4 ثوان، توفر 99.9%
الحجم المفترض	~100 مليون راكب شهري، ~5 مليون سائق نشط، ~20 مليون رحلة يومياً — واذكرها كافتراضات كذلك

مسار المطابقة

المطابقة هي ما يضغط عليه المحاورون، لأنها المكان الذي تلتقي فيه الفهرسة الجغرافية والحالة الفورية وسياسة المهلة معًا.

استعلام الخلايا الثماني المجاورة ليس تحسينًا للأداء — بل تصحيح للصحة. السائق الذي يبعد خمسين مترًا لكنه خلف حد الخلية يكون غير مرئي إن استعلمت خلية الراكب وحدها.

قرارات التصميم الرئيسية

الفهرسة الجغرافية المكانية: قسّم الخريطة إلى خلايا باستخدام geohash (ترميز خط العرض/الطول في سلسلة بادئة). المواقع القريبة تتشارك بادئة geohash. للعثور على سائقين خلال 2 كم، استعلم الخلية الحالية وجيرانها الثمانية.

# دقة Geohash مقابل المساحة
# الدقة 4: ~39 كم × 20 كم (مستوى المدينة)
# الدقة 5: ~5 كم × 5 كم (مستوى الحي)
# الدقة 6: ~1.2 كم × 0.6 كم (مستوى الشارع)
# الدقة 7: ~153 م × 153 م (مستوى البناء)

خوارزمية المطابقة: عندما يطلب راكب، ابحث عن جميع السائقين المتاحين في خلايا geohash القريبة. رتّبهم حسب: (1) المسافة المباشرة (صيغة Haversine)، (2) وقت الوصول المقدر (ETA)، (3) تقييم السائق. أرسل الطلب للسائق الأعلى تصنيفاً. إذا رُفض أو انتهى الوقت (15 ثانية)، جرّب السائق التالي.

تسعير الذروة: احسب نسبة العرض-الطلب لكل منطقة geohash. عندما يتجاوز الطلب العرض بحد معين، طبّق مضاعفاً (1.2x إلى 3.0x، مع حد أقصى). حدّث مناطق الذروة كل دقيقتين. أبلغ الركاب بالمضاعف قبل التأكيد.

حساب الأجرة: الأجرة = الأجرة_الأساسية + (المسافة_كم × المعدل_لكل_كم) + (المدة_دقيقة × المعدل_لكل_دقيقة) × مضاعف_الذروة. طبّق حداً أدنى للأجرة، ثم اخصم عمولة المنصة. لا تذكر نسبة عمولة محددة — فهي تختلف بالسوق وبفئة السائق وبالجهة المنظِّمة، وهي من أكثر الأرقام تغيّرًا في هذا النشاط. اعتبرها قيمة إعداد لكل سوق، وهي أيضًا طريقة تخزينها في نظام حقيقي.

التتبع الفوري: يرسل السائقون تحديثات الموقع كل 4 ثوان عبر WebSocket. خزّن في Redis (geohash → مجموعة سائقين). يشترك الركاب في قناة موقع سائقهم لتحديثات الخريطة الحية.

مشكلة التصميم 3: صمم Google Docs

التحرير التعاوني الفوري شائع بشكل متزايد في المقابلات. يختبر معرفتك بـ CRDTs مقابل OT والاتساق وأنظمة الحضور.

المتطلبات

النوع	المتطلب
وظيفي	إنشاء/تحرير المستندات، تعاون فوري، حضور المؤشر، تاريخ الإصدارات، التحرير دون اتصال
غير وظيفي	زمن مزامنة <100ms، بدون فقدان بيانات عند التعارضات، دعم 100+ محرر متزامن
الحجم المفترض	مئات الملايين من المستخدمين شهريًا، ومليارات المستندات — اختر رقمًا مستديرًا وقل إنه افتراض

قرارات التصميم الرئيسية

OT مقابل CRDTs. غطّت الوحدة الثالثة الآليات، والتصحيح الجدير بالتكرار هنا: يُستشهد بـ Figma روتينيًا بوصفها «الشركة التي استبدلت OT بـ CRDTs»، ومدونتها الهندسية تقول العكس — فهي ذات خادم مركزي ولا تستخدم CRDTs حقيقية صراحةً. إن استشهدت بها، فاستشهد بها كالطريق الأوسط لا كحالة الـ CRDT.

المهم في المقابلة ليس سرد الجدول بل اختيار فرع والدفاع عنه:

نظام الحضور: يُبث موضع مؤشر كل مستخدم ونطاق التحديد إلى المحررين الآخرين عبر WebSocket. استخدم قناة خفيفة لكل مستند. قيّد التحديثات إلى 10-15 في الثانية لتقليل عرض النطاق. اعرض الصور الرمزية/الألوان لكل مؤشر نشط.

تاريخ الإصدارات: خزّن لقطات المستند دورياً (كل N تعديل أو كل M ثانية). استخدم قائمة مرتبطة من الإصدارات — كل إصدار يخزن إما لقطة كاملة أو فرق من الإصدار السابق. اسمح للمستخدمين بالتصفح واستعادة أي إصدار.

الأمان في تصميم الأنظمة

يظهر الأمان في كل جولة تصميم تقريباً. إليك أنماط يجب ذكرها بشكل استباقي:

الطبقة	النمط	متى تُستخدم
المصادقة	OAuth2/OIDC لتسجيل دخول المستخدم، مفاتيح API لخدمة-لخدمة	أي نظام به مستخدمون
التفويض	RBAC للأدوار البسيطة، ABAC للسياسات الدقيقة	أنظمة متعددة المستأجرين
النقل	TLS 1.3 للخارجي، mTLS لخدمة-لخدمة	دائماً
البيانات الساكنة	تشفير AES-256، تشفير مغلف مع KMS	أنظمة تخزن PII أو بيانات مالية
حماية API	تقييد المعدل، التحقق من المدخلات، WAF	أي API عامة
الأسرار	HashiCorp Vault أو AWS Secrets Manager، أبداً في الكود	جميع الأنظمة

نصيحة للمقابلة: حتى إذا لم يسأل المحاور عن الأمان، اذكر باختصار "سأضيف تقييد المعدل عند API gateway وmTLS بين الخدمات." هذا يُظهر الوعي الإنتاجي.

أسئلة تصميم الأنظمة في عصر الذكاء الاصطناعي

تتضمن المقابلات الحديثة بشكل متزايد أسئلة تجمع بين الأنظمة الموزعة التقليدية ومكونات AI/ML:

• "صمم منصة chatbot تخدم 10K محادثة متزامنة مع واجهات LLM خلفية"
• "صمم خدمة توليد صور تعالج 1M طلب/يوم"
• "أضف بحثاً مدعوماً بالذكاء الاصطناعي لمنصة تجارة إلكترونية"

اعتبارات رئيسية لتصميم أنظمة الذكاء الاصطناعي:

• زمن الاستجابة: استدعاء LLM أبطأ بمراتب من قراءة قاعدة بيانات، ويزداد بطئًا حين يستدل النموذج قبل أن يجيب. صمّم لهذه الحقيقة لا حول رقم بعينه: ابثّ الـ tokens تدفقيًا ليكون ما يشعر به المستخدم هو زمن أول token، وخزّن بادئات الأوامر مؤقتًا، وتدرّج بالنماذج ليعالج الصغير الأغلبية السهلة. واقتبس الأرقام الحالية من صفحة النماذج لدى المزوّد إن أراد المحاور تفاصيل — فهي تتغير مع كل إصدار.
• التكلفة: الاستدلال يُحاسَب على الـ tokens الداخلة والخارجة، ما يجعل التكلفة دالة في تصميم الأمر لا في حجم الحركة وحده. خزّن الاستجابات الشائعة مؤقتًا، وجمّع الطلبات حيث يسمح زمن الاستجابة، وحدّد ميزانية tokens لكل مستخدم، واعلم أن أمر نظام مكتوبًا بإهمال ومضروبًا في كل طلب هو عادةً أكبر بند في الفاتورة.
• الأمان: حواجز المدخلات (كشف حقن الأوامر)، حواجز المخرجات (تصفية المحتوى)، والإنسان في الحلقة للقرارات عالية المخاطر.

استراتيجية التواصل في المقابلة

دليل توزيع الـ 45 دقيقة

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

تقنيات التواصل

1. فكّر بصوت عالٍ: اسرد تفكيرك. "أختار Kafka هنا لأننا نحتاج معالجة أحداث مرتبة ودائمة عند 100K رسالة/ثانية."
2. تحقق: بعد كل مرحلة، اسأل "هل هذا الاتجاه منطقي؟ هل يجب أن أتعمق في أي مكون؟"
3. ارسم أثناء الحديث: استخدم مربعات للخدمات، أسطوانات لقواعد البيانات، أسهم لتدفق البيانات. سمِّ كل شيء.
4. اعترف بعدم اليقين: "لست متأكداً 100% من حد أقسام Kafka الدقيق، لكن أعتقد أنه في نطاق الآلاف. النقطة الرئيسية هي أننا سنقسم حسب user_id للترتيب."
5. قدّم بدائل: "يمكننا استخدام Redis Pub/Sub بدلاً من Kafka هنا. المقايضة هي الديمومة — Redis أسرع لكنه لا يحتفظ بالرسائل افتراضياً."

الأخطاء الشائعة والتعافي

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

ما التالي؟

صار لديك الآن الإطار وعادات التقدير وخمس بنيات مشروحة. الفجوة المتبقية هي التكرار — فدليل التوزيع أعلاه لا يصير تلقائيًا إلا بعد تشغيله أمام ساعة حقيقية عدة مرات. وهذه الدورات تواصل التمرين:

• مقابلات تصميم أنظمة الذكاء الاصطناعي — طبّق التفكير في تصميم الأنظمة على بنيات خاصة بالذكاء الاصطناعي: أنظمة RAG وخدمة LLM ومنصات الوكلاء المتعددين وخطوط ML. مثالي إذا كنت تستهدف أدوار هندسة AI/ML.
• مقابلات مهندس Backend — تعمق في مشاكل Backend المحددة مع مختبرات عملية: مختصرات URL ومقيّدات المعدل وتصميم API وأنماط الأنظمة الموزعة.
• مقابلات مهندس السحابة/الحلول — بنية متعددة السحاب وإطار Well-Architected واستراتيجية المؤسسة وتحسين التكاليف على نطاق واسع.
• مقابلات مهندس وكلاء الذكاء الاصطناعي — دورة عملية متميزة حيث تبني خمسة أنظمة وكلاء إنتاجية من الصفر. تغطي استدعاء الأدوات ووكلاء RAG وتنسيق الوكلاء المتعددين وحواجز الأمان.

مقابلة تصميم الأنظمة هي محادثة وليست امتحاناً. هدفك هو إظهار أنك تستطيع التعامل مع الغموض واتخاذ قرارات مُبررة والتواصل بوضوح تحت الضغط. مع الأطر والأنماط من هذه الدورة، أنت جاهز. :::