من المتطلبات إلى أول مخطط معماري
من المتطلبات إلى أول مخطط معماري
تبدأ كل جلسة تصميم أنظمة حقيقية أو مقابلة تقنية بنفس الطريقة: قائمة طويلة من الكلمات — متطلبات وظيفية وقيود غير وظيفية وتقديرات للحجم — وسبورة فارغة. المهارة التي تميّز المهندس المتمرس عن المبتدئ هي القدرة على ترجمة تلك الكلمات إلى مخطط معماري واضح خلال أقل من عشر دقائق. تتناول هذه الدرس هذه العملية خطوة بخطوة من خلال مثال عملي محدد.
لماذا نرسم المخطط مبكراً؟
المخطط الأول ليس وثيقة تصميم تفصيلية، بل هو أداة تواصل. غرضه هو:
- إظهار الافتراضات المشتركة حتى يتمكن الفريق من مناقشتها وتحديها.
- الكشف عن المتطلبات الناقصة قبل كتابة أي سطر كود.
- إبراز أهم المقايضات مبكراً، حين يكون تغييرها غير مكلف.
- منح النقاش مرجعاً ملموساً: "هل يجب وضع الكاش هنا أم هناك؟"
عملية الترجمة في خمس خطوات
تحويل المتطلبات إلى مخطط يتبع تسلسلاً قابلاً للتكرار:
- تحديد الجهات المتفاعلة (Actors). من أو ما الذي يبدأ الطلبات؟ (تطبيقات الجوال، المتصفحات، خدمات خارجية، مهام دفعية.)
- تحديد تدفقات البيانات الأساسية. لكل جهة متفاعلة: ماذا ترسل وماذا تتوقع في المقابل؟
- تسمية الخدمات المنطقية. تجميع المسؤوليات في مربعات مسماة. لكل مربع مهمة واحدة يمكن صياغتها في جملة.
- إضافة موصلات البنية التحتية. أين تحتاج إلى موازن حمل، أو كاش، أو طابور رسائل، أو CDN؟
- تحديد مخازن البيانات. مربع واحد لكل مخزن بيانات مستقل (قاعدة البيانات الرئيسية، فهرس البحث، مخزن الكائنات، الكاش).
هذا التسلسل متعمد في اتجاهه من الخارج إلى الداخل: ابدأ من حدود النظام (الجهات المتفاعلة) ثم اتجه للداخل. لا تبدأ من قاعدة البيانات — فقاعدة البيانات تفصيل تنفيذي للخدمة، وليس العكس.
مثال عملي: خدمة تقصير الروابط
متطلبات تم جمعها في جلسة سابقة:
- وظيفية: تلقي رابط طويل وإعادة كود قصير فريد. تلقي كود قصير وإعادة التوجيه للرابط الأصلي. السماح للمستخدمين اختيارياً بتحديد اسم مخصص.
- غير وظيفية: 100 مليون رابط جديد يومياً (ذروة الكتابة ~1,200 عملية/ثانية)؛ 10 مليارات عملية قراءة وإعادة توجيه يومياً (~115,000 عملية/ثانية)؛ إعادة التوجيه في أقل من 10 مللي ثانية p99؛ توافر 99.99%؛ الروابط لا تنتهي صلاحيتها إلا بحذف المستخدم لها.
- خارج النطاق (للمخطط الأول): لوحة التحليلات، كشف الإساءة، تحديد معدل الطلبات.
الخطوة 1 — تحديد الجهات المتفاعلة
جهتان: متصفح / تطبيق جوال ينشئ روابط قصيرة (مسار الكتابة) ومتصفح / تطبيق جوال يتبع الروابط القصيرة (مسار القراءة). كلاهما من نفس النوع، فيندمجان في مربع واحد عند حافة النظام.
الخطوة 2 — تحديد تدفقات البيانات الأساسية
- كتابة: Client → POST /shorten → يعيد
short_code - قراءة: Client → GET /<code> → إعادة توجيه 301/302 للرابط الأصلي
الخطوة 3 — تسمية الخدمات المنطقية
تظهر مسؤوليتان متمايزتان: خدمة إنشاء الروابط (تستقبل الروابط الطويلة وتولّد الأكواد وتحفظها) وخدمة إعادة التوجيه (تبحث عن الكود وتصدر إعادة التوجيه). فصلهما يتيح تحجيمهما باستقلالية — إعادة التوجيه أكثر تكراراً بمقدار 100 ضعف من الإنشاء.
الخطوة 4 — إضافة موصلات البنية التحتية
مسار القراءة يستقبل 115,000 طلب/ثانية. قاعدة بيانات علائقية تستوعب ما بين 10,000 و30,000 قراءة/ثانية على أجهزة عادية. الحسابات تستوجب وضع كاش أمام قاعدة البيانات (معدل إصابة الكاش 99% → ~1,150 قراءة/ثانية من قاعدة البيانات، سهل التعامل معه). موازن الحمل يجلس أمام كلتا الخدمتين لضرورة التحجيم الأفقي. CDN اختياري لخدمة إعادة التوجيه لكنه يضيف تخزيناً مؤقتاً جغرافياً مفيداً.
الخطوة 5 — تحديد مخازن البيانات
مخزن بيانات رئيسي واحد: قاعدة بيانات قيمة-مفتاح أو علائقية تربط short_code → original_url. بناء على 100 مليون رابط/يوم × 365 يوماً × 5 سنوات = 182 مليار صف، تُعدّ قاعدة بيانات علائقية مجزأة أو متسعة الأعمدة (Cassandra أو DynamoDB) مناسبة. أضف كاش في الذاكرة (Redis) لمسار القراءة الساخن.
قراءة المخطط في مواجهة المتطلبات
عادة بالغة الأهمية: بعد رسم المخطط، اقرأ كل متطلب وتتبّع أين يتحقق. هذا يغلق الحلقة ويكشف الثغرات.
- 100 مليون كتابة/يوم: موازن الحمل يوزع على نسخ متعددة من خدمة إنشاء الروابط. كل نسخة تكتب في قاعدة البيانات المجزأة. ✓
- 10 مليارات قراءة/يوم بأقل من 10 مللي ثانية p99: خدمة إعادة التوجيه تفحص Redis أولاً (بحث محلي أقل من مللي ثانية). نسبة إصابة الكاش المستهدفة: 99%. فقط حالات الإخفاق تصل لقاعدة البيانات. ✓
- توافر 99.99% (52 دقيقة توقف/سنة): كل مربع يجب أن يكون مكرراً. المخطط يفترض نسخاً متعددة خلف موازن الحمل ونسخة احتياطية من قاعدة البيانات — سجّل هذه الافتراضات في ملاحظاتك الآن قبل أن تتقدم المقابلة. ✓
- الروابط لا تنتهي صلاحيتها: لا توجد منطق TTL في المخطط — وهذا مقصود. ✓
أخطاء شائعة في المخطط الأول
- رسم معمارية متراصة بقاعدة بيانات واحدة والاكتفاء بذلك. قد يكون صحيحاً إذا كان الحجم يناسب فعلاً خادماً واحداً — أثبت أنك تحققت من الأرقام.
- إضافة خدمات قبل تبريرها. كل مربع يجب أن يكسب مكانه: "أضفت خدمة تحليلات منفصلة لأن كتابة التحليلات في مسار إعادة التوجيه الساخن ستضيف 5-20 مللي ثانية كمون."
- نسيان اتجاه تدفق البيانات. السهم بدون تسمية اتجاه يبقى غامضاً. حدد دائماً: كتابة أم قراءة، متزامن أم غير متزامن.
- التعامل مع المخطط الأول باعتباره نهائياً. المخطط الأول يجب أن يثير التساؤلات. إذا لم يسأل أحد "لماذا الكاش هنا وليس هناك؟"، فالمخطط على الأرجح مبهم أكثر مما ينبغي.
من الرسمة الأولى إلى التحسين المتكرر
بعد تقديم المخطط الأول، سيتعمق المحاور أو قائد الفريق في أضعف نقطة. سؤال نموذجي: "ماذا يحدث حين يتوقف Redis؟" تتبع المخطط: خدمة إعادة التوجيه ترجع لقاعدة البيانات الرئيسية. إنتاجية القراءة تنخفض إلى ~30,000 قراءة/ثانية — يكفي للنجاة ليس للتعامل مع الذروة. الحل: Redis Sentinel أو Cluster للتبديل التلقائي. حدّث المخطط الآن بملاحظة صغيرة، أو ارسم مخططاً ثانياً يُظهر توبولوجيا Redis Cluster. كل تكرار يجيب عن سؤال ويرفع مستوى الثقة في التصميم.
انضباط الرسم الشامل أولاً ثم التعمق في نقاط الضعف هو جوهر عملية تصميم الأنظمة. المخطط هو الوسيلة؛ والنقاش حوله هو المنتج الحقيقي.