كل منصة SaaS ناجحة تصل إلى اللحظة نفسها: عشرات ثم مئات المستأجرين على البنية ذاتها، وسؤال واحد يحدد مستقبل المنتج — هل صُمم التعدد من الأساس أم رُقّع لاحقًا؟ الفارق بين الحالتين هو الفارق بين نمو هادئ وليالٍ من حوادث تسرب البيانات بين العملاء. في هذا المقال نلخص أنماط العزل والمصادقة والفوترة التي نطبقها في «الشبكة» عند بناء منصات متعددة المستأجرين تنمو بلا ألم.
اختر نموذج العزل بوعي — لا بالمصادفة
قرار العزل هو أهم قرار معماري في المنصة، وله ثلاثة أنماط رئيسية:
- قاعدة بيانات لكل مستأجر — أقوى عزل وأسهل امتثال، لكن كلفة تشغيلية تتضاعف مع كل عميل. مناسب للعملاء الكبار وقطاعات التنظيم الصارم.
- مخطط مشترك بمعرّف مستأجر — الأكفأ تشغيليًا والأسرع نموًا، لكنه يضع كل عبء العزل على انضباط الكود.
- هجين — مخطط مشترك للشريحة العامة، وقواعد مستقلة لمن يدفع مقابل العزل. النمط الذي تنتهي إليه أغلب المنصات الناضجة.
لا يوجد نموذج «صحيح» — يوجد نموذج يطابق عملاءك اليوم ويترك الباب مفتوحًا لعملاء الغد.
معرّف المستأجر يمر في كل طبقة — والدفاع متعدد الخطوط
في النموذج المشترك، أخطر حادثة ممكنة استعلام نسي شرط المستأجر فأظهر بيانات عميل لعميل آخر. الحماية لا تُترك للانتباه البشري بل تُبنى طبقات: سياق مستأجر إلزامي في كل طلب، وطبقة وصول للبيانات تضيف الشرط تلقائيًا ولا تسمح بتجاوزه، وأمان مستوى الصف (RLS) في قاعدة البيانات كخط دفاع أخير يعمل حتى لو أخطأ الكود.
ثم اختبارات آلية تحاول عمدًا الوصول عبر الحدود بين مستأجرين — تفشل الإطلاقة في CI قبل أن تصل الثغرة للإنتاج.
المصادقة: هوية المستخدم شيء وعضويته شيء آخر
النمط الذي يصمد: هوية واحدة للمستخدم، وعضويات متعددة في مستأجرين، وأدوار لكل عضوية. هذا يفتح الحالات الحقيقية بسلاسة — مستشار يعمل مع ثلاث شركات، وموظف ينتقل بين فريقين — دون حسابات مكررة. ومع أول عميل كبير سيأتي طلب SSO (تسجيل الدخول الموحد عبر SAML أو OIDC)؛ ابنِ نقطة التوصيل مبكرًا، فهي شرط صفقات لا ميزة رفاهية.
الفوترة تبدأ من القياس
لا يمكن فوترة ما لا تقيسه. من اليوم الأول، سجّل الاستخدام لكل مستأجر — المستخدمين النشطين، حجم التخزين، استدعاءات الواجهات، أو أي وحدة تعكس القيمة عندك — في مسار أحداث مستقل عن منطق الفوترة نفسه. بعدها تستطيع تركيب أي نموذج تسعير فوق البيانات: باقات، أو دفع بالاستخدام، أو مزيج، وتغييره لاحقًا دون إعادة بناء.
واربط حدود الباقات بالإنفاذ الفعلي: الباقة التي تعد بعشرة مستخدمين يجب أن يفرضها النظام آليًا، مع رسالة ترقية مهذبة لا خطأ غامض.
الجار المزعج: عدالة الموارد
في البنية المشتركة، مستأجر واحد ثقيل — استيراد مليون سجل، أو تكامل مجنون — يمكن أن يبطئ المنصة على الجميع. الوقاية: حدود معدل لكل مستأجر لا للنظام كله، وطوابير معالجة تفصل الأحمال الثقيلة عن المسار التفاعلي، ومراقبة مقسمة بالمستأجر تكشف من يستهلك ماذا قبل أن يشتكي الآخرون.
الترحيلات على أسطول قواعد
إن اخترت قاعدة لكل مستأجر، فكل ترحيل مخطط يصبح عملية على أسطول: أتمتة تنفذ الترحيل تدريجيًا، وتتحقق من نجاحه لكل قاعدة، وتوقف الانتشار عند أول فشل. بدون هذه الأتمتة، سيتباعد المستأجرون في إصدارات المخطط — وهي فوضى يصعب العودة منها.
قائمة تحقق للتعدد بلا ألم
- هل اخترت نموذج العزل قرارًا واعيًا موثقًا — لا افتراضًا ورثته؟
- هل يمر معرّف المستأجر إلزاميًا في كل طبقة، مع RLS كخط دفاع أخير؟
- هل الهوية منفصلة عن العضوية، ونقطة SSO جاهزة للعملاء الكبار؟
- هل تقيس الاستخدام لكل مستأجر من اليوم الأول، والحدود مُنفذة آليًا؟
- هل لديك حدود معدل لكل مستأجر ومراقبة مقسمة تكشف الجار المزعج؟
الخلاصة
تعدد المستأجرين ليس ميزة تضيفها لاحقًا، بل عدسة تصمم من خلالها كل طبقة: العزل، والهوية، والقياس، والعدالة التشغيلية. المنصات التي تبنيه من الأساس تنمو من عشرة عملاء إلى ألف بهدوء؛ والتي ترقّعه تدفع الثمن حوادث وثقة عملاء. الاستثمار المبكر هنا هو أرخص تأمين لمستقبل منتجك.
في «الشبكة» نصمم منصات SaaS متعددة المستأجرين من الصفر ونعالج مشاكل التعدد في المنصات القائمة. إذا كنت تبني منصتك أو تستعد لعميلك الكبير الأول، تواصل معنا.