يبدو نظام SaaS متعدّد المستأجرين (multi-tenant) من الخارج تطبيقاً واحداً؛ أما في الداخل فهو انضباط يحمل بيانات آلاف المنشآت على النواة ذاتها دون أن يمسّ بعضها بعضاً أبداً. وهذا هو الموضوع الثابت للندوة الهندسية التي يقيمها Corex360 شهرياً: قاعدة شيفرة واحدة، وبنية تحتية واحدة، ومع ذلك نظام يشعر كل مستأجر معه وكأنه في عالمه الخاص، فكيف يُبنى؟
العزل: مخطّط أم صفّ؟
القرار الأول والأكثر حسماً هو عزل البيانات. وهناك منهجان رئيسان: مخطّط منفصل لكل مستأجر (schema-per-tenant)، أو وسم كل صفّ في جداول مشتركة بمعرّف tenant_id (row-level). يمنح المنهج القائم على المخطّط فصلاً فيزيائياً قوياً ونسخاً احتياطياً سهلاً، لكن إدارة عشرات الآلاف من المخطّطات تُثقل عمليات الترحيل (migration). أما المنهج القائم على الصفّ فهو خفيف تشغيلياً وقابل للتوسّع؛ غير أن شرط WHERE ناقصاً واحداً يُعدّ كارثة. وعملياً يفوز الحلّ الهجين: عزل على مستوى الصفّ لمعظم الوحدات + سياسات أمان على مستوى الصفّ (RLS) مفروضة على مستوى قاعدة البيانات، وفصل منطقي للمستأجرين المؤسسيين الكبار.
المهمّ هو فرض العزل في أدنى طبقة ممكنة، لا الاعتماد على شيفرة التطبيق. فالمطوّر الذي ينسى يوماً إضافة مرشّح tenant_id يدوياً إلى كل استعلام سيسرّب بيانات مستأجر آخر. لذلك يُضمَّن المرشّح في سياسة قاعدة البيانات وفي طبقة الاستعلام المشتركة؛ بحيث لا يستطيع المطوّر تجاوزه حتى لو أراد.
في البنية متعدّدة المستأجرين، الأمان ليس ميزة بل سلوك افتراضي؛ ليس استثناءً بل قاعدة.
نواة واحدة، مزامنة فورية
في Corex360، ينبغي أن تظهر الرسالة الواردة من WhatsApp في اللحظة ذاتها في صندوق الوارد، وعلى بطاقة CRM، وفي لوحة BI. ونحلّ ذلك لا باستعلام كل شاشة باستمرار، بل بعمود فقري قائم على الأحداث (event-driven): حين يحدث شيء، رسالة جديدة، أو فاتورة صادرة، أو مركبة تتحرّك، يبثّ النظام حدثاً، فتستمع إليه الوحدات المعنية وتحدّث نفسها. وحتى مع خدمة نواة واحدة لآلاف المستأجرين، تتنقّل أحداث كل مستأجر داخل حدوده وحدها.
تُبقي هذه البنية الوحدات مترابطة ترابطاً مرناً. لا يلزم وحدة تتبّع المركبات أن تعرف البنية الداخلية لوحدة المخزون؛ فكلتاهما تتحدّثان لغة الأحداث ذاتها. وإضافة وحدة جديدة ليست إعادة كتابة للنواة، بل إضافة مستمِع جديد إلى المسار. وسرّ التوسّع ليس إدارة الحجم، بل إدارة الاستقلالية.
الصلاحيات على مستوى المستأجر وKVKK/GDPR
في تركيا KVKK، وفي أوروبا GDPR، وكلاهما يطلب إجابة واضحة عن سؤال «لمن تعود البيانات ومن يستطيع رؤيتها». وفي نظام متعدّد المستأجرين، يعني هذا تفويضاً من طبقتين: أولاً حدّ المستأجر (لا يستطيع مستخدِم منشأة قطّ الوصول إلى بيانات منشأة أخرى)، ثم الأدوار داخل المستأجر (يرى المشرف الميداني بيانات المركبة، ويرى المحاسب الفاتورة، وليس كلٌّ كل شيء).
الوجه العملي للامتثال هو القابلية للتدقيق: من وصل إلى أيّ بيانات ومتى؛ وعند طلب حذف بيانات مستأجر، أن يُحذف أثر ذلك المستأجر وحده فعلاً وفقط؛ وأن تكون مدد الاحتفاظ بالبيانات قابلة للتطبيق على مستوى كل مستأجر. والبنية متعدّدة المستأجرين الجيّدة تحمل KVKK لا بوصفه طبقة امتثال مُلصَقة لاحقاً، بل بوصفه نتيجة طبيعية لقرار العزل.
