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

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

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

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

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

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

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

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

جولات البرمجة بمساعدة الذكاء الاصطناعي. بدأت Meta في أواخر 2025 تجربة جولة برمجة مدعومة بالذكاء الاصطناعي تحل محل إحدى جولتي البرمجة التقليديتين. يعمل المرشح في بيئة CoderPad مع مساعد مدمج ويستطيع تبديل النماذج أثناء الجلسة، والمهمة مشروع متعدد الملفات وليست مسألتي خوارزميات. ينتقل التقييم نحو الحكم: هل تستطيع توجيه المساعد، وهل تلتقط ما يخطئ فيه. وبما أن قائمة النماذج المتاحة تتغير من ربع لآخر، لا يستحق حفظها — راجع مواد التحضير الحالية من الشركة التي تقابلها.

الأثر غير المباشر أهم من الجولة نفسها. حين يستطيع المساعد إنتاج تصميم معقول في ثوانٍ، لم يعد الفارق في الاستحضار — بل في قدرتك على تمييز التصميم المعقول من التصميم الصحيح.

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

إطار RESHADED

RESHADED نهج منظم من دورة Grokking the System Design Interview لدى Educative. ثمانية أحرف، وسبع أو ثماني مراحل حسب ما إذا كانت المشكلة تستحق رسم مخطط تخزين:

تطبيق 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	قرص دوار
رحلة شبكة ذهاباً وإياباً (نفس مركز البيانات)	~100–500 μs	نفس منطقة التوفر ~100 μs؛ عبر مناطق التوفر ~300–500 μs
رحلة شبكة ذهاباً وإياباً (عبر القارات)	~150 ms	أمريكا إلى أوروبا

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

كل تقدير في هذه الجولة هو نفس السلسلة ذات الخطوات الخمس: مستخدمون ← إجراءات ← QPS ← ذروة ← تخزين وعرض نطاق. حرّك المدخلات وراقب أي مخرج ينهار أولاً — هذا هو الرقم الذي ستصمم حوله في النهاية.

الخطوة التي يتخطاها معظم المرشحين هي مضاعف الذروة. الحركة ليست مستوية عبر 86,400 ثانية، والتصميم المقاس على المتوسط ينهار في الثامنة مساءً.

مثال — خلاصة شبيهة بـ 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: حتى عندما لا يوجد تقسيم — وهي الحالة الغالبة — تظل تواجه مقايضة بين زمن الاستجابة والاتساق. وهذا هو النصف الأكثر فائدة، لأن التقسيمات نادرة بينما قرارات زمن الاستجابة دائمة.

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

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

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

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

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

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

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