توسيع VionexLMS: بنية متعددة المستأجرين للتعلم المؤسسي

الخيار: تجميع، عزل، أو هجين

عند بناء نظام تعلم للمؤسسات، أول مفترق معماري هو نموذج تعدد المستأجرين. ثلاثة أنماط تسود:

1. قاعدة بيانات لكل مستأجر — أقوى عزل، وأصعب تشغيلًا.
2. تجميع مع عزل على مستوى الصف — أرخص تشغيلًا، وأضعف لو نسي استعلام مرشّح المستأجر.
3. هجين — مخطط مشترك، مُجزّأ بمعرّف المستأجر، مع سياسات أمان على مستوى الصف.

اخترنا الهجين.

كيف يبدو المخطط

كل جدول مرتبط بمستأجر يحوي عمود org_id غير قابل للإفراغ، وفهرسًا فريدًا جزئيًا على (org_id, ...)، وسياسة أمان صف في Postgres تُرشّح على current_setting('app.org_id'). التطبيق يضبط app.org_id لكل طلب، قبل أول استعلام، في وسيط واحد.

هذا ما لا يتحدث عنه أحد: لا يمكنك الوثوق بترشيح ORM وحده. نسيان واحد لـ .filter(org_id=...) يجعل مستأجرًا يرى اختبار مستأجر آخر. أمان الصف هو الأرضية تحت الـ ORM.

سجلات التدقيق

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

استراتيجية CDN

وسائط المستأجرين برابط موقّع خلف CloudFront. محتوى الكتالوج العام يُخزّن مؤقتًا بقوة. حدود المعدل لكل مستأجر تعيش على الحافة، لا على خادم التطبيق، لمنع الجيران المزعجين من الإضرار بالبقية.

النتيجة: 24 مستأجرًا على بنية مشتركة، بلا تداخل، وزمن عرض الصفحة p95 تحت 400 مللي ثانية.