لماذا تهمّ بنية تعدد المستأجرين في منتجات SaaS
بنية تعدد المستأجرين (Multi-Tenancy) قرار تصميمي أساسي في أي منتج SaaS. فهي تحدد كيف يتعامل تطبيقك مع عملاء متعددين — من عزل البيانات وأمانها إلى كفاءة التكلفة وقابلية التوسع.
ما المقصود بتعدد المستأجرين؟
في النظام متعدد المستأجرين، تخدم نسخة واحدة من التطبيق عملاء متعددين (مستأجرين). تُعزل بيانات كل مستأجر منطقياً بينما تتشارك جميعها البنية التحتية نفسها، مما يقلل التكاليف التشغيلية ويبسّط عمليات النشر.
منهجنا
في IT Smart App، يعتمد كل منتج نبنيه أسلوب مخطط منفصل لكل مستأجر (schema-per-tenant) مع PostgreSQL. وهذا يمنحنا:
- عزلاً كاملاً للبيانات — بيانات كل مستأجر في نطاق اسم خاص به
- علامة تجارية مخصصة — شعارات وألوان وإعدادات لكل منشأة
- إدارة مركزية — قاعدة شيفرة واحدة، ونشر واحد، وعملاء متعددون
- كفاءة في التكلفة — موارد حوسبة مشتركة مع بيانات معزولة
مثال من الواقع
يخدم نظام إدارة المقاهي والمطاعم لدينا مطاعم متعددة من نشر واحد. كل مطعم يرى طلباته وقوائمه وتحليلاته فقط — بينما نحافظ نحن على قاعدة شيفرة واحدة مع خطوط تكامل ونشر موحّدة.
قرارات تقنية جوهرية
- 1أمان مستوى الصف (RLS) — سياسات Row-Level Security في PostgreSQL تضمن ألا تتسرب البيانات بين المستأجرين
- 2وسيط مدرك للمستأجر — كل طلب API يُقيَّد تلقائياً بالمستأجر الموثَّق
- 3ترحيلات مخطط مشتركة — تُنفَّذ ترحيلات Alembic مرة واحدة وتُطبَّق على جميع المستأجرين
- 4إعدادات مستقلة — يخصص كل مستأجر إعداداته التشغيلية دون التأثير على غيره
متى تختار تعدد المستأجرين؟
يكون هذا الأسلوب مثالياً عندما:
- تبني منتج SaaS موجّهاً للشركات
- يحتاج العملاء وظائف متشابهة مع تخصيص محدود
- تريد تقليل تكاليف البنية التحتية عند التوسع
- يهمّك النشر والمراقبة من مكان مركزي
أما في المنتجات التي تفرض فيها المتطلبات التنظيمية فصلاً مادياً للبيانات، فينبغي النظر في بنية تحتية مخصصة لكل مستأجر — لكن في معظم تطبيقات الأعمال، يوفّر العزل المنطقي التوازن الصحيح بين الأمان والكفاءة.
*مهتم بمعرفة كيف تفيد بنية تعدد المستأجرين منتجك؟ تواصل معنا لمناقشة متطلباتك.*