مقالات

معمارية تعدّد المستأجرين: القرارات التي لا يمكن التراجع عنها

معمارية · تعدّد المستأجرين · SaaS

تعدّد المستأجرين ليس طبقة تُضاف لاحقاً. أربعة قرارات تُحسم قبل أول خاصية — العزل، وتحديد المستأجر، والهوية، والكلفة — ولماذا يصعب التراجع عن كلٍّ منها.

تعدّد المستأجرين هو أن يخدم نشرٌ واحد عملاء كثيرين، يرى كلٌّ منهم النظام وكأنه له وحده. والمسألة التي تجعل هذه المعمارية صعبة ليست تقنية بحتة: أربعة قرارات تُحسم في الشهر الأول، وكلها تمتدّ إلى نموذج البيانات وكل استعلام وكل مهمّة خلفية — فيصير التراجع عنها بعد أن يحتفظ عملاء حقيقيون ببياناتهم في النظام أشبه بإعادة بناء منه بتعديل.

هذه المادة أصل محاضرة قدّمتها في Arabic Dev Group Malaysia، وهي مكتوبة هنا بتوسّع أكبر ممّا يسمح به نصف ساعة.

ما الذي يعنيه «معزول» فعلاً؟

العزل ليس خياراً ثنائياً بين قاعدة بيانات لكل عميل وقاعدة واحدة مشتركة؛ بل طيف، وموضعك عليه قرار تجاري يرتدي ثياباً تقنية:

النموذجالعزلالكلفة لكل مستأجرالترحيلات
قاعدة بيانات لكل مستأجرالأقوىتنمو مع عدد العملاءتُنفَّذ ن مرّة، وقد تفشل جزئياً
مخطَّط لكل مستأجرقويمتوسطةن مرّة، لكن على خادم واحد
جداول مشتركة بمُعرّف مستأجريعتمد على انضباط الشيفرةقريبة من الصفرمرّة واحدة

الخطأ الشائع هو اختيار الأقوى عزلاً لأنه «الأأمن». وهو فعلاً الأأمن أمام عميل مؤسّسي يشترط ذلك في العقد، لكنه يربط كلفتك التشغيلية بعدد عملائك — وإن كانت لديك خطّة مجانية، فأنت تدفع عن كل حساب لا يدفع لك شيئاً.

في مَكّوك، الخطّة المجانية دائمة وبلا عمولة. هذا القيد وحده استبعد كل تصميم تنمو كلفته مع عدد المستأجرين، فتبعت المعمارية النموذج التجاري لا العكس. وهذا هو الترتيب الصحيح: النموذج التجاري أولاً، ثم العزل.

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

كيف يعرف النظام أي مستأجر يخاطبه؟

قبل أي منطق عمل، على كل طلب أن يُحلَّ إلى مستأجر واحد محدّد. الطرق المتاحة ثلاث، ولها آثار متباينة:

  • نطاق فرعي أو نطاق مخصّص — الأوضح للعميل، والأقرب إلى شعوره بأن المنتج له. وثمنه أن تصير إدارة الشهادات وسجلّات DNS جزءاً من منتجك.
  • مسار في الرابط — الأبسط تشغيلياً، والأضعف في الإحساس بالملكية.
  • من هوية المستخدم — يعمل داخل التطبيق، ويفشل في كل ما لا يحمل جلسة: الويب هوك، والمهام المجدولة، وواجهات التكامل.

الحالة التي تُنسى دائماً هي ما لا يأتي من متصفّح. مهمّة ليلية تعالج كل المستأجرين لا تملك سياقاً واحداً؛ ويب هوك من مزوّد دفع يصل بمُعرّف المزوّد لا بمُعرّفك. إن لم يكن تحديد المستأجر مسألةً مركزية في التصميم، ظهرت هذه الحالات متفرّقة لاحقاً، وعولجت كلٌّ منها بطريقة مختلفة.

القاعدة العملية: اجعل تسريب استعلام عبر المستأجرين مستحيلاً افتراضياً لا ممنوعاً بالمراجعة. مرشّح على مستوى الوصول إلى البيانات يُطبَّق تلقائياً، والاستثناء منه يحتاج تصريحاً صريحاً في الشيفرة — وهذا أنفع من أي عدد من مراجعات الأقران، لأنه يفشل على الفرع لا في التشغيل الفعلي.

هل المستخدم يخصّ مستأجراً واحداً؟

أسهل افتراض هو أن كل مستخدم ينتمي إلى مستأجر واحد، وأول عميل جادّ سيكسره: محاسب يخدم ثلاث شركات، أو موظّف انتقل بين فرعين، أو شريك يحتاج وصولاً محدوداً إلى حسابات عملائه.

الفصل الذي يحلّ هذا هو بين من أنت وماذا يحقّ لك، وأين. الهوية تخصّ الشخص ولا تتكرّر، والعضوية هي الرابط بين شخص ومستأجر، وهي التي تحمل الصلاحيات. بهذا يصير انضمام المستخدم إلى مستأجر ثانٍ إضافة سجلّ، لا حساباً جديداً ببريد بديل.

لماذا يصعب التراجع: حين يكون البريد الإلكتروني مفتاحاً فريداً داخل جدول مرتبط بمستأجر، فإن فصل الهوية عن العضوية لاحقاً يعني دمج حسابات موجودة يملك كلٌّ منها بيانات وسجلّ نشاط — وهي عملية تحتاج قراراً بشرياً في كل حالة متعارضة.

هل يقيس النظام الاستهلاك من البداية؟

الخطط والسقوف تبدو مسألة فوترة، وهي في الحقيقة مسألة قياس. إن لم يكن النظام يعرف كم استهلك كل مستأجر — عدد الطلبات، حجم التخزين، عدد المستخدمين، عدد الرسائل — فلا يمكن فرض سقف ولا تسعير حسب الاستهلاك ولا حتى معرفة أي عميل يكلّفك أكثر ممّا يدفع.

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

القرار الأدنى المطلوب في البداية: أن يكون لكل عملية ذات كلفة مُعرّف مستأجر مسجَّل معها. لا حاجة إلى نظام فوترة في الشهر الأول؛ الحاجة إلى ألّا تكون البيانات مفقودة حين يُبنى ذلك النظام.

ما الذي يمكن تأجيله فعلاً

ليس كل شيء في تعدّد المستأجرين قراراً مبكراً، ومعرفة ما يمكن تأجيله تحرّر وقتاً للقرارات الأربعة السابقة:

  • السِّمات البصرية والتخصيص — يمكن أن تبدأ بحدّها الأدنى وتتوسّع، ما دامت إعدادات لا شيفرة تعمل لعميل واحد.
  • لوحة الإدارة الذاتية للمستأجر — يمكن أن تكون في البداية عملية يدوية تقوم بها أنت، شرط أن تكون ممكنة دون عميل قاعدة بيانات.
  • العزل على مستوى البنية التحتية — إن صُمِّم الوصول إلى البيانات بمرشّح مركزي من البداية، بقي الانتقال إلى عزل أقوى ممكناً لاحقاً لعميل واحد يشترطه.

الخيط الجامع بين الأربعة الأولى أنها تلمس كل شيء، وبين هذه الثلاثة أنها موضعية.

الخلاصة

القرارات الأربعة — أين تقف على طيف العزل، وكيف يُحدَّد المستأجر في كل مسار بما فيه ما لا يحمل جلسة، وهل الهوية منفصلة عن العضوية، وهل الاستهلاك مقيس — تُحسم قبل أول خاصية أو تُدفع كلفتها إعادةَ بناء لاحقاً. وثلاثتها الأولى بالذات لا تظهر أعراضها مبكراً: النظام يعمل تماماً بعميل واحد، ثم بعشرة، ثم يظهر العميل الذي يكسر الافتراض.

هذا ما أبنيه للعملاء، وما أُشغّله بنفسي في مَكّوك، وما أُدرّسه للفرق الهندسية.

العودة إلى المدونة ←