BLOG //
دروس من بناء SaaS متعدد المستأجرين على Laravel
المنتجات متعددة المستأجرين تنجح عندما يكون «المستأجر» أول-class citizen في الكود، وليس عمودًا نُسيه في بعض الجداول. في مشاريع ERP وحجز وخدمات B2B التي عملت عليها، تعلمت أن أبسط نموذج يعمل غالبًا أفضل من الحل الأكثر ذكاءً على الورق.
ابدأ بتحديد استراتيجية عزل واضحة: قاعدة بيانات لكل مستأجر، مخطط (schema) لكل مستأجر، أو صف مشترك مع tenant_id. للأسواق المتوسطة في الخليج، غالبًا يكفي tenant_id مع فهارس صارمة وسياسات وصول في طبقة التطبيق، شرط أن كل استعلام يمر عبر scope موحد.
طبقة التطبيق في Laravel تستفيد من: Middleware يحدد المستأجر من النطاق أو الرأس، Form Requests تمنع تسريب معرفات، Jobs تحمل سياق المستأجر، واختبارات تؤكد أن مستأجر A لا يرى بيانات B أبدًا. تجنب الاعتماد على «تذكر إضافة where» في كل Controller.
عند التوسع، راقب ثلاثة مؤشرات: زمن استعلامات التقارير، حجم تخزين الملفات لكل مستأجر، وتعقيد التكاملات الخارجية (دفع، SMS، بريد). التوسع الحقيقي يأتي من حدود واضحة لكل خطة (plan) وواجهات إدارة تشغيلية، لا من ميزات جديدة فقط.
ابدأ بتحديد استراتيجية عزل واضحة: قاعدة بيانات لكل مستأجر، مخطط (schema) لكل مستأجر، أو صف مشترك مع tenant_id. للأسواق المتوسطة في الخليج، غالبًا يكفي tenant_id مع فهارس صارمة وسياسات وصول في طبقة التطبيق، شرط أن كل استعلام يمر عبر scope موحد.
طبقة التطبيق في Laravel تستفيد من: Middleware يحدد المستأجر من النطاق أو الرأس، Form Requests تمنع تسريب معرفات، Jobs تحمل سياق المستأجر، واختبارات تؤكد أن مستأجر A لا يرى بيانات B أبدًا. تجنب الاعتماد على «تذكر إضافة where» في كل Controller.
عند التوسع، راقب ثلاثة مؤشرات: زمن استعلامات التقارير، حجم تخزين الملفات لكل مستأجر، وتعقيد التكاملات الخارجية (دفع، SMS، بريد). التوسع الحقيقي يأتي من حدود واضحة لكل خطة (plan) وواجهات إدارة تشغيلية، لا من ميزات جديدة فقط.