محصول B2B یعنی صدها مشتری سازمانی (tenant) روی یک سیستم: دادهشان باید کاملاً جدا بماند، یکی نباید بقیه را کند کند، و مشتری بزرگ گاهی «زیرساخت اختصاصی» میخواهد. این سه نیروی متضاد، معماری SaaS را میسازند.
طیف ایزولاسیون
| مدل | ساختار | قوت | قیمت |
|---|---|---|---|
| Pool | همه tenant ها در منابع مشترک؛ جدایی با tenant_id در هر کوئری | ارزانترین، سادهترین عملیات | ریسک noisy neighbor؛ یک WHERE فراموششده = نشت داده |
| Bridge | اشتراکی برای اغلب + اختصاصی برای مشتریان بزرگ/حساس | تطبیق با قراردادها | دو مدل برای نگهداشت |
| Silo | هر tenant استک/دیتابیس خودش | ایزولاسیون و compliance مطلق | هزینه و پیچیدگی عملیاتی ×N |
الگوهای کلیدی
- هر سطر داده tenant_id دارد و enforce کردنش باید ماشینی باشد: Row-Level Security در Postgres یا میانافزار اجباری — اعتماد به «یادم میماند WHERE بزنم» ممنوع.
- Noisy Neighbor: tenant بزرگ نباید صفحه بقیه را کند کند — سهمیه per-tenant (rate limit فصل ۴)، صفهای جدا برای کارهای سنگین، و معماری سلولی (Cell-Based): هر سلول یک استک کامل برای برشی از tenant ها؛ انفجار یک سلول، بقیه را نمیبرد (مدل AWS).
- Sharding بر اساس tenant_id طبیعی است؛ ولی tenant نهنگ را جدا کن (shard اختصاصی) تا توازن حفظ شود.
- Data Residency: مقررات گاهی داده مشتری اروپایی را در اروپا میخواهد — region را به tenant بچسبان؛ این با home region فصل ۹ خواه خوشحال است.
- Metering از روز اول: مصرف هر tenant (درخواست، ذخیره، محاسبه) را ثبت کن — هم مبنای billing است هم رادار سوءاستفاده.
DIAGRAMمعماری سلولی
Router — tenant → cell
→
Cell 1 — استک کامل
→
Cell 2 — استک کامل
→
Cell N
به زبان ساده
Multi-tenancy یعنی صدها مشتری روی یک سیستم؛ دادهها باید با tenant_id جدا بمانند و یک مشتری پرمصرف نباید بقیه را کند کند.
مثال واقعی
مثل ساختمان اداری: همه ساختمان را شریکاند (ارزان)، اما کلید دفتر هر شرکت جداست و اگر یکی مهمانی پرسر و صدا گرفت، مدیر ساختمان (سهمیه و سلول) جلویش را میگیرد.