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

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

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

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

المتطلبات

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

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

مسار الرفع:
  العميل → API Gateway → خدمة الرفع → تخزين الكائنات (S3)
                                              ↓
                                    خط معالجة الترميز (Kafka → Workers)
                                              ↓
                                    CDN Origin → خوادم الحافة

مسار التشغيل:
  العميل → CDN Edge → Origin (إذا لم يوجد) → تخزين الكائنات
                    → ملف Manifest (HLS/DASH معدل بت تكيفي)

التوصية:
  نشاط المستخدم → Kafka → خط الميزات → نموذج ML → خدمة التوصية

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

ترميز الفيديو: حوّل مقاطع الفيديو المرفوعة إلى دقات متعددة (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، مع حد أقصى). حدّث مناطق الذروة كل دقيقتين. أبلغ الركاب بالمضاعف قبل التأكيد.

حساب الأجرة: الأجرة = الأجرة_الأساسية + (المسافة_كم × المعدل_لكل_كم) + (المدة_دقيقة × المعدل_لكل_دقيقة) × مضاعف_الذروة. طبّق حداً أدنى للأجرة. اخصم عمولة السائق (عادة 20-25%).

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

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

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

المتطلبات

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

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

OT مقابل CRDTs:

الجانب	OT (التحويل العملياتي)	CRDTs (أنواع البيانات المُكررة الخالية من التعارض)
يُستخدم بواسطة	Google Docs	Figma (تحوّلت من OT في 2019)
متطلب الخادم	خادم تحويل مركزي	لامركزي (نظير لنظير ممكن)
دعم عدم الاتصال	محدود (يحتاج الخادم للتحويلات)	أصلي (دمج عند إعادة الاتصال)
التعقيد	دوال التحويل تنمو مع أنواع العمليات	تصميم بنية البيانات معقد مسبقاً
الاتساق	قوي (عبر الخادم)	نهائي (تقارب مضمون)

في المقابلة: اوصِ بـ CRDTs إذا أكد السؤال على التحرير دون اتصال أو المزامنة نظير لنظير. اوصِ بـ OT إذا كان الاتساق القوي عبر خادم مركزي مقبولاً.

نظام الحضور: يُبث موضع مؤشر كل مستخدم ونطاق التحديد إلى المحررين الآخرين عبر 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 يستغرق 500ms-5s لكل طلب. استخدم استجابات تدفقية وتخزين مؤقت للأوامر وتتالي النماذج (نموذج سريع للاستعلامات البسيطة، نموذج كبير للمعقدة).
• التكلفة: مكالمات API لـ LLM مكلفة. خزّن الاستجابات الشائعة مؤقتاً، جمّع الطلبات حيث أمكن، وحدد ميزانيات tokens لكل مستخدم.
• الأمان: حواجز المدخلات (كشف حقن الأوامر)، حواجز المخرجات (تصفية المحتوى)، والإنسان في الحلقة للقرارات عالية المخاطر.

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

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

الوقت	المرحلة	ماذا تفعل
0-5 دقائق	المتطلبات	اطرح أسئلة توضيحية. أكد المتطلبات الوظيفية وغير الوظيفية. حدد الحجم.
5-10 دقائق	التقدير	قم بحسابات الظهر-المغلف. حدد QPS والتخزين وعرض النطاق.
10-25 دقيقة	التصميم عالي المستوى	ارسم البنية. عرّف المكونات وتدفق البيانات وAPIs.
25-40 دقيقة	التعمق	تعمق في 1-2 مكونات حرجة يهتم بها المحاور.
40-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 وتنسيق الوكلاء المتعددين وحواجز الأمان.

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