أساسيات تصميم الأنظمة
إطار عمل تصميم الأنظمة
مقابلات تصميم الأنظمة تختبر قدرتك على تصميم أنظمة واسعة النطاق. على عكس جولات البرمجة، لا توجد إجابة صحيحة واحدة -- يقيّم المقابلون عملية تفكيرك وتحليل المفاضلات والتواصل.
إطار العمل من 4 خطوات
استخدم هذا الهيكل لكل مقابلة تصميم أنظمة:
الخطوة 1: توضيح المتطلبات (5 دقائق)
اطرح أسئلة لتضييق النطاق. قسّمها إلى:
المتطلبات الوظيفية (ما يفعله النظام):
- ما هي الميزات الأساسية؟
- من هم المستخدمون؟
- ما هي حالات الاستخدام الرئيسية؟
المتطلبات غير الوظيفية (كيف يعمل النظام):
- كم عدد المستخدمين؟ (النطاق)
- ما زمن الاستجابة المقبول؟
- هل الاتساق أم التوفر أكثر أهمية؟
- ما نسبة القراءة إلى الكتابة؟
مثال: "صمم مختصر روابط"
- وظيفي: إنشاء رابط قصير، إعادة التوجيه للرابط الطويل، أسماء مستعارة مخصصة اختيارية
- غير وظيفي: 100 مليون رابط/شهر، زمن إعادة توجيه أقل من 100ms، توفر 99.9%
الخطوة 2: التقدير السريع (5 دقائق)
حسابات سريعة لفهم النطاق:
تقديرات مختصر الروابط:
- 100 مليون رابط جديد/شهر = ~40 رابط/ثانية (كتابة)
- نسبة القراءة:الكتابة = 100:1 → 4,000 قراءة/ثانية
- التخزين: 100 مليون × 500 بايت = 50 جيجابايت/شهر
- 5 سنوات: 50 جيجابايت × 60 = 3 تيرابايت إجمالي
- عرض النطاق: 4,000 × 500 بايت = 2 ميجابايت/ثانية
صيغ رئيسية:
- QPS (استعلامات في الثانية) = إجمالي الطلبات / الثواني في الفترة
- التخزين = عدد السجلات × متوسط حجم السجل
- عرض النطاق = QPS × متوسط حجم الاستجابة
الخطوة 3: التصميم عالي المستوى (10-15 دقيقة)
ارسم المكونات الرئيسية وتفاعلاتها:
العميل → موزع الحمل → خوادم API → قاعدة البيانات
↓
الكاش (Redis)
لمختصر الروابط:
- طبقة API: POST /shorten (إنشاء)، GET /:code (إعادة توجيه)
- توليد المعرّفات: ترميز Base62 أو قائم على التجزئة
- التخزين: قاعدة بيانات لربط الروابط
- الكاش: Redis للروابط الساخنة (معظم الروابط تتبع توزيع القوة)
الخطوة 4: التعمق (15-20 دقيقة)
المقابل يختار مناطق للاستكشاف. كن مستعدًا لمناقشة:
- اختيار قاعدة البيانات والمخطط
- استراتيجية التخزين المؤقت
- معالجة الحالات الحدية
- عنق الزجاجة في التوسع
نظرية CAP
في نظام موزع، يمكنك ضمان اثنتين فقط من ثلاث:
| الخاصية | المعنى | مثال |
|---|---|---|
| الاتساق (Consistency) | كل قراءة تعيد آخر كتابة | المعاملات البنكية |
| التوفر (Availability) | كل طلب يحصل على استجابة | موجز وسائل التواصل |
| تحمل التقسيم (Partition Tolerance) | النظام يعمل رغم أعطال الشبكة | أي نظام موزع |
عمليًا: تقسيمات الشبكة حتمية، لذا الاختيار الحقيقي بين CP (متسق لكن قد يكون غير متوفر) و AP (متوفر لكن قد يقدم بيانات قديمة).
نظرية PACELC
توسيع لـ CAP: حتى بدون تقسيمات، هناك مفاضلة بين زمن الاستجابة و الاتساق.
| النظام | أثناء التقسيم | التشغيل العادي |
|---|---|---|
| DynamoDB | AP (متوفر) | EL (زمن منخفض) |
| PostgreSQL | CP (متسق) | EC (متسق) |
| Cassandra | AP (متوفر) | EL (قابل للضبط) |
التالي: لنغطي اللبنات الأساسية التي تظهر في كل تصميم نظام. :::