مسائل تصميم الأنظمة الكلاسيكية

هذه المسائل الخمس تظهر بشكل متكرر في المقابلات. معرفة حلولها تبني الذاكرة العضلية لمعالجة أي مسألة تصميم.

1. مختصر الروابط (مثل bit.ly)

المتطلبات: توليد روابط قصيرة، إعادة التوجيه للأصلي، التعامل مع حركة قراءة عالية.

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

المكوّن	الاختيار	لماذا
توليد المعرّفات	ترميز Base62 (a-z, A-Z, 0-9)	62^7 = 3.5 تريليون كود فريد
قاعدة البيانات	NoSQL (DynamoDB)	بحث مفتاح-قيمة بسيط، إنتاجية عالية
الكاش	Redis	قاعدة 80/20: 20% من الروابط تحصل على 80% من الحركة
البنية	كثيفة القراءة	نسبة قراءة:كتابة 100:1

المسار:

إنشاء: العميل → API → توليد المعرّف → التخزين في DB → إعادة الرابط القصير
إعادة التوجيه: العميل → CDN/كاش → DB (عند الفقدان) → إعادة توجيه 301

2. محدد المعدل (Rate Limiter)

المتطلبات: تحديد طلبات API لكل مستخدم/IP لمنع الإساءة.

الخوارزميات:

الخوارزمية	كيف تعمل	المزايا	العيوب
Token Bucket	إضافة رموز بمعدل ثابت، كل طلب يستهلك رمزًا	يسمح بالانفجارات، سلس	يحتاج ضبط
Sliding Window Log	تتبع أوقات الطلبات في نافذة	دقيق	كثيف الذاكرة
Sliding Window Counter	جمع عدادات النافذة الثابتة مع حساب منزلق	ذاكرة منخفضة، دقيق كفاية	تقريبي
Fixed Window	عدّ الطلبات في نوافذ زمنية ثابتة	بسيط	مشكلة انفجار الحدود

أين يوضع: بوابة API أو كوسيط. استخدم Redis لتحديد المعدل الموزع عبر خوادم متعددة.

3. نظام المحادثة (مثل WhatsApp/Slack)

المتطلبات: مراسلة 1:1، محادثات جماعية، حالة الاتصال، سجل الرسائل.

المكونات الرئيسية:

العملاء ↔ خوادم WebSocket ↔ طابور رسائل (Kafka)
                                    ↓
                              مخزن الرسائل
                              (Cassandra)

القرار	الاختيار	لماذا
البروتوكول	WebSocket	ثنائي الاتجاه، فوري، اتصال مستمر
تخزين الرسائل	Cassandra	كثيف الكتابة، بيانات سلسلة زمنية، تقسيم بـ chat_id
تسليم الرسائل	دفع (WebSocket) + سحب (عند إعادة الاتصال)	تسليم موثوق
حالة الاتصال	Redis مع TTL	بحث سريع، انتهاء تلقائي
رسائل المجموعات	Fan-out عند الكتابة (مجموعات صغيرة) أو عند القراءة (مجموعات كبيرة)	مفاضلة: تضخم الكتابة مقابل زمن القراءة

4. موجز الأخبار (مثل Twitter/Facebook)

المتطلبات: المستخدمون ينشرون محتوى، المتابعون يرون المنشورات بترتيب زمني/مرتب.

نهجان:

النهج	كيف	المزايا	العيوب
Fan-out عند الكتابة	عند النشر، ادفع لموجز جميع المتابعين	قراءة سريعة	كتابة بطيئة للمشاهير (ملايين المتابعين)
Fan-out عند القراءة	عند فتح الموجز، اسحب من المتابَعين	كتابة سريعة	قراءة بطيئة، يحتاج دمج
هجين	Fan-out عند الكتابة للعاديين، عند القراءة للمشاهير	متوازن	أكثر تعقيدًا

البنية:

خدمة النشر → خدمة Fan-out → كاش الموجز (Redis)
                                      ↓
                                خدمة الموجز → العميل

5. خدمة الإشعارات

المتطلبات: إرسال إشعارات دفع/بريد/SMS بموثوقية على نطاق واسع.

التصميم:

حدث المشغّل → خدمة الإشعارات → طابور الأولوية
                                        ↓
                                ┌───────┼───────┐
                                ↓       ↓       ↓
                              دفع    بريد    SMS
                             (APNs/  (SES)  (Twilio)
                              FCM)

اعتبارات رئيسية:

إزالة التكرار: مفاتيح عدم التكرار لمنع الإشعارات المكررة
تحديد المعدل: لا تُغرق المستخدمين
الأولوية: الإشعارات العاجلة تتجاوز الطابور
إعادة المحاولة: تراجع أسّي مع طابور رسائل ميتة للفشل
القوالب: إدارة قوالب مركزية للاتساق

قالب إجابة تصميم الأنظمة

عند شرح أي تصميم، اتبع هذا الهيكل:

"النظام يحتاج..." (المتطلبات)
"على هذا النطاق، هذا يعني..." (التقدير)
"البنية عالية المستوى هي..." (المخطط)
"لـ [المكوّن]، سأختار [X] لأن..." (قرارات مبررة)
"المفاضلة هنا هي..." (تُظهر النضج)
"للتعامل مع [الحالة الحدية]، سنقوم..." (يُظهر العمق)

التالي: لنغطي أنماط التوسع والموثوقية -- المواضيع التي تميّز المرشحين ذوي الخبرة. :::