مقابلة تصميم الأنظمة في 2026

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

ما يُقيّمه المحاورون فعلياً

تُقيّم مقابلات تصميم الأنظمة أربعة أبعاد في وقت واحد:

البُعد	ما يبحثون عنه	علامات تحذيرية
التفكير المعماري	هل تستطيع تفكيك مشكلة غامضة إلى مكونات واضحة؟	القفز للحلول دون جمع المتطلبات
تحليل المقايضات	هل تفهم لماذا اخترت X بدلاً من Y؟	الادعاء بأن نهجاً ما "أفضل دائماً"
التواصل	هل تستطيع شرح تصميمك بوضوح مع التفكير بصوت عالٍ؟	فترات صمت طويلة أو الكلام بدون هيكل
الوعي الإنتاجي	هل تأخذ بالاعتبار أوضاع الفشل والمراقبة والتوسع؟	تصميم المسار السعيد فقط

رؤية أساسية: يهتم المحاورون بـ عمليتك أكثر من تصميمك النهائي. تصميم مُبرَّر جيداً مع قيود معترف بها يتفوق على تصميم "مثالي" لا تستطيع شرحه.

كيف يتطور شكل المقابلة

تظل الجولة التقليدية لمدة 45 دقيقة على السبورة البيضاء هي المعيار في معظم الشركات. لكن المشهد يتغير:

جولة Meta للبرمجة بمساعدة الذكاء الاصطناعي (أُطلقت في أكتوبر 2025): استبدلت Meta إحدى جولتي البرمجة بجلسة مدعومة بالذكاء الاصطناعي. يعمل المرشحون في بيئة CoderPad مع مساعد AI (تشمل النماذج GPT-4o mini وClaude 3.5 Haiku). ينتقل التركيز من كتابة الكود من الصفر إلى إظهار الحكم التقني — معرفة متى تعتمد على اقتراحات AI ومتى تستخدم تفكيرك الخاص.

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

إطار RESHADED

RESHADED هو نهج منظم طوّرته Educative لدورتهم Grokking the System Design Interview. كل حرف يمثل مرحلة:

R — Requirements: توضيح المتطلبات الوظيفية وغير الوظيفية
E — Estimation: حسابات تقدير الظهر-المغلف للحجم
S — Storage: اختيار التخزين المناسب للبيانات
H — High-level design: رسم البنية من ارتفاع 1000 قدم
A — APIs: تعريف واجهات واضحة بين المكونات
D — Detailed design: التعمق في 1-2 مكونات حرجة
E — Evaluation: مناقشة المقايضات والاختناقات والتحسينات
D — Distinctive component: إبراز ما يجعل هذا النظام فريداً

تطبيق RESHADED: مثال سريع

السؤال: "صمم خدمة تحليلات URL تتتبع أحداث النقر."

المرحلة	ما تفعله
R	وظيفي: تسجيل النقرات وعرض لوحة تحليلات. غير وظيفي: معالجة 100K نقرة/ثانية، زمن كتابة <200ms
E	100K كتابة/ثانية × 200 بايت = 20 MB/s وارد. 100K × 86400 = 8.6 مليار حدث/يوم → ~1.7 TB/يوم تخزين خام
S	قاعدة بيانات سلاسل زمنية للأحداث (InfluxDB أو ClickHouse). Redis للعدادات الفورية. PostgreSQL لبيانات URL الوصفية
H	API Gateway → Kafka → Consumer → Time-series DB. مسار قراءة منفصل: خدمة التجميع → Cache → Dashboard API
A	POST /api/click (كتابة)، GET /api/analytics/{url_id}?range=7d (قراءة)
D	التعمق في خط استيعاب البيانات: تقسيم Kafka حسب URL ID، توسيع مجموعة المستهلكين، دلالات التنفيذ مرة واحدة بالضبط
E	مقايضة: الاتساق النهائي في لوحة التحكم (مقبول للتحليلات). اختناق: عدد أقسام Kafka يحد من التوازي
D	مميز: اكتشاف الشذوذ الفوري في أنماط النقر (كشف الروبوتات)

إتقان تقديرات الظهر-المغلف

التقدير هو المكان الذي يتألق فيه معظم المرشحين أو يتعثرون. الهدف ليس الدقة — بل إظهار تفكير منظم حول الحجم.

جدول مرجعي لقوى العدد 2

القوة	القيمة الدقيقة	التقريب
2^10	1,024	~1 ألف
2^20	1,048,576	~1 مليون
2^30	1,073,741,824	~1 مليار
2^40	~1.1 × 10^12	~1 تريليون

أرقام مرجعية لزمن الاستجابة

تساعدك هذه الأرقام على فهم أين يذهب الوقت في الطلب:

العملية	زمن الاستجابة	ملاحظات
مرجع ذاكرة L1 cache	~1 ns	ذاكرة المعالج
مرجع ذاكرة L2 cache	~4 ns	ذاكرة المعالج
مرجع الذاكرة الرئيسية	~100 ns	RAM
قراءة عشوائية SSD	~16 μs	قرص محلي
قراءة عشوائية HDD	~2 ms	قرص دوار
رحلة شبكة ذهاباً وإياباً (نفس مركز البيانات)	~500 μs	داخل منطقة AWS
رحلة شبكة ذهاباً وإياباً (عبر القارات)	~150 ms	أمريكا إلى أوروبا

سير عمل التقدير

1. ابدأ بالمستخدمين النشطين يومياً (DAU)
2. حوّل إلى QPS: DAU × الإجراءات_لكل_مستخدم / 86400
3. طبّق مضاعف الذروة: QPS × 2-5 (نسبة الذروة للمتوسط)
4. قسّم القراءة/الكتابة: نسبة نموذجية 10:1 إلى 100:1 قراءة لكتابة
5. احسب التخزين: write_QPS × حجم_الكائن × أيام_الاحتفاظ
6. احسب عرض النطاق: QPS × حجم_الحمولة (وارد + صادر)
7. قدّر البنية التحتية: الخوادم = peak_QPS / سعة_الخادم

مثال — خلاصة شبيهة بـ Twitter:

# المعطيات
dau = 300_000_000          # 300 مليون مستخدم نشط يومياً
tweets_per_user_per_day = 2
read_to_write_ratio = 100  # 100 قراءة لكل كتابة

# QPS (استعلامات في الثانية)
write_qps = dau * tweets_per_user_per_day / 86400  # ~6,944 كتابة/ثانية
peak_write_qps = write_qps * 3                      # ~20,833 كتابة/ثانية (3x ذروة)
read_qps = write_qps * read_to_write_ratio           # ~694,444 قراءة/ثانية
peak_read_qps = read_qps * 3                         # ~2,083,333 قراءة/ثانية

# التخزين (يومياً)
avg_tweet_size_bytes = 500  # نص + بيانات وصفية
daily_storage = write_qps * 86400 * avg_tweet_size_bytes  # ~300 GB/يوم
yearly_storage = daily_storage * 365                       # ~109 TB/سنة

# عرض النطاق
write_bandwidth = peak_write_qps * avg_tweet_size_bytes   # ~10 MB/s وارد
read_bandwidth = peak_read_qps * 2000                     # ~4 GB/s صادر (حمولة الخلاصة أكبر)

أنماط تحليل المقايضات

نظرية CAP

في نظام موزع يواجه تقسيم شبكة، يجب أن تختار بين:

• الاتساق (C): كل قراءة تُرجع أحدث كتابة
• التوفر (A): كل طلب يتلقى استجابة (ليس بالضرورة أحدث البيانات)

نوع النظام	الاختيار	مثال
المصرفية/المدفوعات	CP (اتساق + تحمل التقسيم)	Spanner، CockroachDB
خلاصات التواصل الاجتماعي	AP (توفر + تحمل التقسيم)	Cassandra، DynamoDB
ملفات المستخدمين	قابل للضبط	PostgreSQL مع نسخ قراءة (اتساق نهائي للقراءات)

نظرية PACELC

امتداد لـ CAP: حتى عندما لا يوجد تقسيم (التشغيل العادي)، تواجه مقايضة بين زمن الاستجابة والاتساق.

إذا تقسيم → اختر التوفر أو الاتساق (CAP)
وإلا → اختر زمن الاستجابة أو الاتساق (PACELC)

مثال: DynamoDB هو PA/EL — أثناء التقسيمات يختار التوفر، وأثناء التشغيل العادي يختار زمن استجابة منخفض (قراءات متسقة نهائياً افتراضياً).

معايرة المستوى

تتدرج توقعات تصميم الأنظمة مع المستوى:

المستوى	العمق المتوقع	مثال
L4 (مبتدئ-متوسط)	صمم مكوناً واحداً بشكل جيد. غطِّ المقايضات الأساسية.	"صمم ذاكرة مؤقتة مع إخلاء"
L5 (أقدم)	نظام شامل مع حدود مكونات واضحة ومعالجة الفشل.	"صمم نظام إشعارات"
L6 (Staff)	تفكير على مستوى المنصة. تبعيات عبر الفرق. تأثير تنظيمي.	"صمم منصة تجريب للشركة"
L7+ (Principal)	بنية على مستوى الصناعة. رؤية تقنية متعددة السنوات.	"صمم البنية التحتية لتعلم الآلة الفوري على نطاق واسع"

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

الخطأ	استراتيجية التعافي
القفز للحل دون متطلبات	"دعني أتراجع وأوضح ما نُحسّن من أجله"
الانحصار في مكون واحد	"أريد التأكد من تغطية الصورة الكاملة. دعني أرسم المستوى العالي أولاً ثم نتعمق"
عدم القدرة على التقدير	"دعني أفكر من المبادئ الأساسية — كم مستخدم، كم مرة يتصرفون، ما حجم كل إجراء"
الإفراط في الهندسة	"للمنتج الأولي يمكننا البدء بـ X والتطور إلى Y عند التوسع"
الرسم بدون شرح	اسرد كل قرار: "أضيف ذاكرة مؤقتة هنا لأن نسبة القراءة للكتابة 100:1"

في الوحدة التالية، نتعمق في أنماط بنية البيانات — مصادر الأحداث وCQRS والمعاملات الموزعة — التي تفتح فئة جديدة من إجابات المقابلات. :::