سهولة التوسع

نحن نعلم أن الأنظمة المترابطة بشدة هي أنظمة هشة. يتم استخدام الميكرو-وحدات أو الهيكل القائم على الخدمات حتى لو كانت أحادية. يتم التجميع حسب الميزات/المجالات، وليس حسب طبقات التقنية (تصميم مدفوع بالمجال الخفيف). يتم فصل الواجهة الأمامية/الخلفية عبر عقود API (OpenAPI، GraphQL). الفوائد: سهل عزل أو توسيع أو استبدال الوحدات دون كسر النظام بالكامل.

نختار بيئات تشغيل قابلة للتوسع بشكل شامل (بشكل رئيسي Node.js) للخلفية. يتم استخدام PostgreSQL، وقواعد البيانات المتوافقة مع PostgreSQL السحابية، وSupabase، وFirebase إذا لزم الأمر. يتم دمج Redis لحركة المرور الثقيلة للقراءة أو التخزين المؤقت. يتم استخدام بنية تحتية سحابية أصلية وDocker: AWS / GCP / — مع دعم التوسع التلقائي. يتم تجنب الأدوات الغامضة التي لا يمكن أن تتوسع أفقيًا أو تفتقر إلى دعم المجتمع.

نحن نعلم أن كل شيء لا يحتاج إلى الحدوث في الوقت الحقيقي. يتم تحميل المهام طويلة الأمد أو الخلفية (البريد الإلكتروني، معالجة الصور، الفوترة) إلى قوائم الانتظار، إلخ. مثال: بعد تسجيل المستخدم، يتم معالجة الفوترة/البريد الإلكتروني في الخلفية، وليس في الخط. يساعد هذا في تحسين الأداء وقابلية التوسع.

نحن نعلم أن المخطط السيئ = إعادة العمل في المستقبل. يتم استخدام واجهات برمجة التطبيقات ذات الإصدارات (/api/v1/...) لمنع كسر العملاء. يتم تفضيل UUIDs على المعرفات التزايدية (على سبيل المثال، لدمج البيانات عبر المناطق). التخطيط للتعددية السكنية (خصوصًا في SaaS): الفصل على مستوى الصف مقابل الفصل على مستوى المخطط، إضافة tenant_id مبكرًا.

نحن نعلم أنك لا تستطيع توسيع ما لا يمكنك رؤيته. يتم استخدام أدوات مثل Sentry لتتبع أخطاء الواجهة الأمامية؛ Prometheus للرؤية في الخلفية/البنية التحتية؛ PostHog و Google Analytics لتحليلات المنتجات؛ واستمرار الفحوصات لمراقبة التوقف. تم إعداد التنبيهات (Slack/البريد الإلكتروني) للأعطال، تراكم الطوابير، ارتفاعات قاعدة البيانات، وما إلى ذلك.

نحن نعلم أن الأنظمة الأحادية يمكن أن تتوسع، لكن الخدمات غير الحالة تتوسع بشكل أفضل. يتم تجنب تخزين جلسات المستخدمين في الذاكرة المحلية — يتم استخدام Redis/متاجر الجلسات. يتم جعل الخوادم غير حالة حتى يمكن تكرارها بسهولة. يتم استخدام الحاويات: Docker + منسقون (مقدمو الخدمات السحابية). هذا يمكّن من التوسع التلقائي دون جلسات ملتصقة أو اختناقات في الذاكرة المشتركة.

نحن نعلم أن المزيد من المستخدمين = المزيد من سطح الهجوم. تم إعداد أنماط RBAC/ABAC (التحكم في الوصول بناءً على الدور). يتم تطبيق تحديد المعدل، والتحقق من المدخلات، ورؤوس الأمان. يتم الاحتفاظ بالأسرار في خزائن ويتم تدويرها.

طبقة API: يتم تنفيذ تحديد المعدل، والترقيم، وتوحيد GraphQL (إذا لزم الأمر). الواجهة الأمامية: يتم استخدام التحميل الكسول، واستضافة CDN، وتقسيم الكود. يتم استخدام التوسع التلقائي. قاعدة البيانات: يتم إعادة فهرسة الفهارس، ويتم التخطيط للتجزئة إذا لزم الأمر، وهكذا.