معماری Multi-Tenant در SaaS چیست؟ طراحی امن چندمستاجری برای نرم افزار SaaS
معماری Multi-Tenant به چند شرکت اجازه میدهد از یک SaaS استفاده کنند بدون اینکه دادههایشان با هم ترکیب شود. در این مقاله مدلهای دیتابیس، امنیت، Tenant Isolation و Scale را بررسی میکنیم.
A
تیم تحریریه آرکوتکتحریریه مهندسی محصول
·۱۷ دقیقه مطالعه
معماری Multi-Tenant و جداسازی امن داده مشتریان در نرم افزار SaaS
خلاصه اجرایی
معماری Multi-Tenant به چند شرکت اجازه میدهد از یک SaaS استفاده کنند بدون اینکه دادههایشان با هم ترکیب شود. در این مقاله مدلهای دیتابیس، امنیت، Tenant Isolation و Scale را بررسی میکنیم.
# معماری Multi-Tenant در SaaS چیست؟ طراحی امن چندمستاجری برای نرم افزار SaaS
یکی از مهمترین تصمیمها هنگام طراحی یک محصول SaaS، انتخاب معماری Multi-Tenant مناسب است.
فرض کنید نرم افزار شما توسط ۵۰۰ شرکت استفاده میشود.
هر شرکت دارای:
کاربران
مشتریان
پروژهها
فایلها
گزارشها
است.
تمام این شرکتها از یک Product استفاده میکنند.
اما یک Rule غیرقابل مذاکره وجود دارد:
هیچ Tenant نباید بتواند Data Tenant دیگر را مشاهده یا تغییر دهد.
همین مسئله پایه معماری چندمستاجری است.
Multi-Tenant چیست؟
Multi-Tenancy مدلی است که چند Customer مستقل از یک Application مشترک استفاده میکنند.
هر Customer یا Organization یک Tenant محسوب میشود.
مثلاً SaaS مدیریت آموزشگاه:
Tenant A:
آموزشگاه تهران
Tenant B:
آموزشگاه شیراز
Tenant C:
آموزشگاه کرج
هرکدام:
مدیر
مدرس
دانشجو
کلاس
خود را دارند.
اما Application اصلی مشترک است.
Tenant چیست؟
Tenant معمولاً یک مرز تجاری و امنیتی است.
میتواند:
شرکت
سازمان
کلینیک
فروشگاه
مدرسه
باشد.
تمام Dataهای عملیاتی باید به Tenant مرتبط باشند.
چرا Multi-Tenancy مهم است؟
بدون طراحی درست، مشکلات جدی ایجاد میشوند:
نشت Data
گزارش اشتباه
Permission ناقص
Backup دشوار
Query کند
Scale نامناسب
در SaaS، اشتباه Multi-Tenancy فقط Bug ساده نیست؛ میتواند Incident امنیتی جدی باشد.
اگر این شرط فراموش شود، احتمال Data Leak وجود دارد.
Tenant Context
Application باید بعد از Authentication بداند User در کدام Tenant قرار دارد.
مثلاً:
Session
↓
User
↓
Membership
↓
Tenant
سپس تمام عملیات در همان Context اجرا شوند.
Membership Model
User ممکن است عضو چند Tenant باشد.
مثلاً Consultant در:
Company A
و
Company B
عضویت داشته باشد.
بنابراین بهتر است Relation جدا وجود داشته باشد.
User
↓
Membership
↓
Tenant
هر Membership میتواند Role متفاوت داشته باشد.
Role per Tenant
User ممکن است:
در Tenant A:
Admin
در Tenant B:
Member
باشد.
پس Role همیشه نباید مستقیم روی User ذخیره شود.
معماری Data Multi-Tenant
سه مدل رایج وجود دارد:
Shared Database + Shared Schema
Shared Database + Separate Schema
Separate Database per Tenant
هرکدام مزایا و محدودیتهای متفاوتی دارند.
مدل اول: Shared Database و Shared Schema
تمام Tenantها در یک Database و Table مشترک هستند.
مثلاً:
customers
دارای ستون:
tenant_id
است.
مزایا:
سادهتر برای Operation
هزینه کمتر
Migration آسانتر
Scale اولیه مناسب
این مدل برای بسیاری از SaaSها رایج است.
ریسک Shared Schema
اگر Query بدون Tenant Filter اجرا شود:
SELECT * FROM customers
ممکن است Data همه Tenantها برگردد.
بنابراین Isolation باید Systematic باشد.
نباید Developer هر بار به خاطر بسپارد tenant_id اضافه کند.
Middleware Tenant
میتوان Tenant Context را در Middleware یا Data Access Layer enforce کرد.
هدف این است که Access بدون Tenant تا حد ممکن غیرممکن یا دشوار شود.
ORM Scope
بعضی Architectureها Queryها را از Repository یا ORM Layer عبور میدهند.
در این Layer Tenant Filter به شکل مرکزی اعمال میشود.
این روش خطر Human Error را کاهش میدهد.
Row-Level Security
در بعضی Databaseها میتوان Row-Level Security یا RLS استفاده کرد.
Policy مشخص میکند User فقط Rowهای Tenant خودش را ببیند.
این Layer میتواند Defense in Depth ایجاد کند.
اما Configuration آن باید دقیق و تستشده باشد.
مدل دوم: Separate Schema
هر Tenant Schema جدا دارد.
مثلاً:
tenant_a.customers
tenant_b.customers
مزایا:
Isolation بیشتر
Data Separation واضحتر
اما:
Migration پیچیدهتر
تعداد Schema بالا
Operations دشوارتر
میشود.
چه زمانی Separate Schema مفید است؟
برای SaaSهایی با:
تعداد Tenant کمتر
Data حساستر
نیاز به Isolation بالاتر
میتواند مناسب باشد.
اما تصمیم باید براساس Architecture واقعی گرفته شود.
مدل سوم: Separate Database
هر Tenant Database مستقل دارد.
مثلاً:
db_company_a
db_company_b
مزایا:
Isolation قوی
Backup مستقل
Scaling مستقل
معایب:
مدیریت پیچیده
هزینه بیشتر
Migration دشوار
Connection Management
است.
Enterprise Tenant
گاهی Product Hybrid است.
Customerهای عادی:
Shared Database
Customer Enterprise:
Dedicated Database
این مدل میتواند Feature Enterprise باشد.
Hybrid Multi-Tenancy
Architecture ترکیبی اجازه میدهد Tenantهای خاص Infrastructure جدا داشته باشند.
مثلاً:
Standard Plan:
Shared
Enterprise:
Dedicated
این مدل Flexibility بالایی دارد اما Operations پیچیدهتر میشود.
چگونه مدل مناسب را انتخاب کنیم؟
باید چند سؤال پاسخ داده شود:
چند Tenant داریم؟
هر Tenant چقدر Data دارد؟
Security Requirement چیست؟
Backup مستقل لازم است؟
Region خاص لازم است؟
Cost Constraint چیست؟
بعد مدل انتخاب شود.
Security Requirement
اگر Product Data بسیار حساس دارد، Isolation ممکن است اولویت بیشتری نسبت به Cost داشته باشد.
اگر Product SMB با Data کم است، Shared Schema شاید بهترین Balance باشد.
Data Residency
برخی Customerها ممکن است بخواهند Data در Region خاص نگهداری شود.
مثلاً:
EU
Middle East
US
در SaaS Enterprise این Requirement میتواند Architecture را تغییر دهد.
Tenant Identification
Tenant چگونه مشخص میشود؟
روشهای رایج:
Subdomain
Domain
Workspace ID
User Selection
مثلاً:
company.arrcotech.app
Subdomain میتواند Tenant Identifier باشد.
Custom Domain
Enterprise Customer ممکن است Domain اختصاصی بخواهد.
مثلاً:
portal.customer.com
این قابلیت نیازمند:
DNS
SSL
Domain Mapping
است.
Authentication در Multi-Tenant
Authentication پاسخ میدهد:
User چه کسی است؟
Authorization پاسخ میدهد:
User در این Tenant چه کاری میتواند انجام دهد؟
این دو باید جدا باشند.
User Membership
بعد از Login، User ممکن است چند Workspace ببیند.
مثلاً:
Workspace A
Workspace B
سپس یکی را انتخاب کند.
Tenant Context بر اساس Workspace فعال تعیین میشود.
جلوگیری از Tenant Spoofing
نباید فقط Tenant ID فرستادهشده از Front-end را Trust کرد.
مثلاً Request:
tenant_id = 123
Backend باید بررسی کند User واقعاً Membership این Tenant را دارد.
URL Tenant ID کافی نیست
اگر URL شامل:
/tenant/123/projects
باشد، Backend نباید فرض کند User Access دارد.
Membership باید Verify شود.
Broken Access Control
یکی از خطرات رایج، تغییر ID در URL یا Request است.
مثلاً User:
/invoice/100
را به:
/invoice/101
تغییر دهد.
اگر Invoice 101 متعلق به Tenant دیگر باشد و Backend کنترل نکند، Data Leak ایجاد میشود.
Object-Level Authorization
هر Entity حساس باید بررسی کند:
Record Tenant
==
Current Tenant
این Validation حیاتی است.
Permission در Tenant
Multi-Tenancy فقط Data Separation نیست.
داخل Tenant نیز Roleها وجود دارند.
مثلاً:
Owner
Admin
Manager
Member
هر Role Permission متفاوت دارد.
RBAC
Role-Based Access Control یعنی Permission براساس Role تعریف شود.
مثلاً:
Admin:
Create User
Member:
View Project
این مدل ساده و رایج است.
ABAC
Attribute-Based Access Control پیشرفتهتر است.
مثلاً:
User فقط Projectهای Department خودش را ببیند.
این Complexity فقط در صورت نیاز واقعی باید اضافه شود.
Owner
معمولاً Tenant یک Owner دارد.
Owner ممکن است بتواند:
Billing
Delete Workspace
Transfer Ownership
را مدیریت کند.
این Actionها حساس هستند.
Invite User
Flow نمونه:
Admin
↓
Invite Email
↓
Token
↓
User Accepts
↓
Membership Created
Invite Token باید:
Expiration
Secure Randomness
One-Time Use
داشته باشد.
حذف User از Tenant
حذف Membership نباید User Account جهانی را الزاماً حذف کند.
چون User ممکن است عضو Tenant دیگری نیز باشد.
این یکی از تفاوتهای مهم Data Model است.
Tenant Deletion
اگر Customer Workspace را حذف کرد چه؟
نباید بلافاصله همه Data پاک شود مگر Policy چنین باشد.
ممکن است:
Soft Delete
Grace Period
Final Delete
وجود داشته باشد.
Soft Delete
Record حذفشده ابتدا Mark میشود.
مثلاً:
deleted_at
بعد در مدت مشخص قابل Recovery است.
اما Queryهای عادی نباید Soft Deleted Data را نشان دهند.
Data Export
قبل از Cancellation ممکن است Customer بخواهد Data خود را Export کند.
این قابلیت اعتماد به SaaS را افزایش میدهد.
Backup Multi-Tenant
Backup Shared Database ساده است.
اما Restore فقط یک Tenant پیچیدهتر میشود.
فرض کنید Company A Data خود را اشتباه حذف کرده است.
Restore کل Database Production منطقی نیست.
پس Tenant-Level Recovery باید در Architecture بررسی شود.
Tenant-Level Backup
در SaaSهای حساس میتوان Snapshot یا Export دورهای Tenant داشت.
اما این Feature Cost و Complexity اضافه میکند.
Logging
Log باید Tenant ID داشته باشد.
مثلاً:
tenant_id
user_id
request_id
این اطلاعات Debug را بسیار سادهتر میکنند.
Error Monitoring
وقتی Error رخ میدهد باید بدانیم:
کدام Tenant؟
کدام User؟
کدام Request؟
بدون این Context Debug سخت میشود.
Audit Log
Enterprise SaaS معمولاً Audit Log نیاز دارد.
مثلاً:
User A
Changed
Invoice X
At Time Y
Audit نیز باید Tenant-Isolated باشد.
Metrics per Tenant
گاهی لازم است Usage هر Tenant اندازهگیری شود.
مثلاً:
Storage
API Calls
Active Users
AI Usage
این Data برای Billing یا Capacity Planning استفاده میشود.
Usage Limit
Plan ممکن است محدودیت داشته باشد.
مثلاً:
Starter:
5 Users
10 GB Storage
Pro:
50 Users
100 GB Storage
سیستم باید Usage را Track کند.
Feature Entitlement
هر Tenant براساس Plan به Featureهای خاص دسترسی دارد.
مثلاً:
Starter:
Basic Report
Pro:
Automation
Enterprise:
SSO
این مفهوم Feature Entitlement است.
Entitlement باید Backend باشد
فقط مخفیکردن Button کافی نیست.
Backend نیز باید بررسی کند Tenant به Feature دسترسی دارد.
Billing و Tenant
Subscription معمولاً به Tenant متصل است، نه User.
یعنی Company Plan خریداری میکند.
Plan
↓
Tenant
↓
Members
این مدل برای B2B SaaS رایج است.
Seat Limit
اگر Plan پنج User دارد، Invite ششم باید Block یا Upgrade Prompt ایجاد کند.
این Rule باید Transaction-Safe باشد.
Usage-Based Billing
اگر Billing براساس API Call است، Usage باید دقیق ثبت شود.
Race Condition و Duplicate Event میتوانند Billing را خراب کنند.
Idempotency
در Billing و Webhookهای SaaS بسیار مهم است.
اگر Payment Provider Event را دوبار ارسال کرد، سیستم نباید Subscription را دو بار تغییر دهد.
Webhook Tenant Context
Eventهای خارجی نیز باید به Tenant صحیح Map شوند.
مثلاً:
subscription_id
↓
tenant_id
این Mapping باید امن باشد.
Storage Path
برای Fileها میتوان Path منطقی داشت:
tenant/{tenant_id}/files/...
اما Path بهتنهایی Security نیست.
Download همچنان باید Authorization داشته باشد.
Signed URL
برای File خصوصی میتوان Signed URL کوتاهعمر تولید کرد.
این روش از Public URL دائمی امنتر است.
Search Multi-Tenant
Search Index نیز باید Tenant-Aware باشد.
اگر Search Engine جدا دارید، هر Document باید Tenant ID داشته باشد.
Query فقط همان Tenant را جستوجو کند.
Cache Multi-Tenant
Cache Key باید Tenant را شامل شود.
بد:
customer:123
بهتر:
tenant:45:customer:123
در غیر این صورت Data Tenantها ممکن است در Cache Mix شود.
یکی از خطرناکترین Bugها
Cache Leak میتواند Data User دیگر را نمایش دهد حتی اگر Database Query درست باشد.
پس Tenant Context باید در تمام Layerها وجود داشته باشد:
Database
Cache
Search
Files
Queue
Background Jobs
Job نیز باید Tenant ID داشته باشد.
مثلاً:
Send Monthly Report
Tenant: 45
اگر Job بدون Context اجرا شود، ممکن است Data اشتباه پردازش کند.
Queue
Payload باید حداقل Context لازم را داشته باشد.
مثلاً:
tenant_id
user_id
resource_id
اما اطلاعات حساس غیرضروری داخل Queue ارسال نشوند.
Cron Jobs
Jobهای دورهای ممکن است روی تمام Tenantها اجرا شوند.
مثلاً:
Daily Invoice Reminder
بهتر است Tenantها Batch شوند تا Load کنترل شود.
Noisy Neighbor
در Shared SaaS، یک Tenant بسیار پرمصرف ممکن است Performance دیگران را کاهش دهد.
این مشکل Noisy Neighbor نام دارد.
جلوگیری از Noisy Neighbor
روشها:
Rate Limit
Queue
Resource Quota
Dedicated Tier
هستند.
Rate Limit per Tenant
بهجای فقط Rate Limit per IP، میتوان Limit براساس Tenant داشت.
مثلاً Plan Pro Request بیشتری داشته باشد.
Database Query
هر Query باید Efficient باشد.
Index ترکیبی میتواند:
tenant_id + created_at
یا:
tenant_id + status
باشد.
این Pattern در Multi-Tenant Database بسیار رایج است.
Index Design
اگر tenant_id تقریباً در تمام Queryها وجود دارد، Indexها باید این Pattern را در نظر بگیرند.
اما Index بیش از حد Write Performance را کاهش میدهد.
Unique Constraint
یکی از نکات مهم:
Unique Value ممکن است در Scope Tenant باشد.
مثلاً Project Name شاید در هر Tenant Unique باشد.
پس Constraint:
UNIQUE(tenant_id, name)
بهتر از:
UNIQUE(name)
است.
Email Unique
User Email ممکن است Global Unique باشد یا per Tenant.
این تصمیم Data Model را تغییر میدهد.
در Membership Model معمولاً User جهانی و Membership جدا است.
Sequence Number
Invoice Number ممکن است برای هر Tenant جدا باشد.
مثلاً:
Company A:
INV-001
Company B:
INV-001
پس Sequence Tenant-Aware لازم است.
Time Zone
هر Tenant ممکن است Time Zone متفاوت داشته باشد.
تاریخ در Database بهتر است استاندارد ذخیره و در UI براساس Tenant نمایش داده شود.
Locale
Tenant ممکن است:
Language
Currency
Number Format
مختلف داشته باشد.
این Settings بهتر است روی Tenant ذخیره شوند.
Currency
Multi-Currency پیچیدهتر از نمایش Symbol است.
اگر عملیات مالی واقعی وجود دارد، Currency Ruleها باید دقیق طراحی شوند.
Tenant Settings
تنظیمات میتواند شامل:
Logo
Language
Timezone
Currency
Notifications
باشد.
این قابلیت White-Label را نیز سادهتر میکند.
White Label
برخی SaaSهای B2B اجازه میدهند Customer:
Logo
Colors
Domain
را تغییر دهد.
White Label Scope جدا و قابل توجهی دارد.
Custom Domain
برای White Label معمولاً Domain Mapping لازم است.
SSL Provisioning و Tenant Resolution نیز باید طراحی شوند.
SaaS و Region
در Scale بالا ممکن است Tenantها براساس Region تقسیم شوند.
مثلاً:
EU Cluster
US Cluster
این Architecture برای Data Residency یا Latency مفید است.
اما برای MVP معمولاً ضروری نیست.
Sharding
در Scale بسیار بالا ممکن است Tenantها بین Databaseهای مختلف تقسیم شوند.
مثلاً:
Shard 1 → Tenant 1-1000
Shard 2 → Tenant 1001-2000
این Complexity باید فقط در صورت نیاز واقعی اضافه شود.
Migration Database
یکی از چالشهای Multi-Tenant Migration است.
در Shared Schema سادهتر است:
یک Migration روی Database.
در Separate Database باید Migration روی چند Database اجرا شود.
Automation مناسب ضروری است.
Versioning Tenant
گاهی Customer Enterprise ممکن است Feature Release متفاوت داشته باشد.
اما نگهداری Versionهای متعدد Product هزینه زیادی دارد.
بهتر است تا حد امکان Single Codebase حفظ شود.
Feature Flag بهتر از Fork
بهجای Codebase جدا برای هر Customer، Feature Flag میتواند Customization را کنترل کند.
Forkهای متعدد Maintenance را بسیار سخت میکنند.
Custom Feature برای یک Customer
یکی از ریسکهای B2B SaaS این است که Product به مجموعهای از Custom Projectها تبدیل شود.
Feature اختصاصی باید بررسی شود:
آیا برای Market گستردهتر Value دارد؟
اگر نه، شاید Integration یا Config بهتر باشد.
Configuration vs Customization
SaaS خوب تا حد ممکن Configurable است.
مثلاً:
Custom Field
Workflow
Branding
اما بدون Fork Code برای هر Tenant.
این Design Scale تجاری را بهتر میکند.
امنیت Multi-Tenant
Security Review باید سناریوهای Cross-Tenant را جدی بگیرد.
مثلاً:
User Tenant A تلاش کند:
Resource Tenant B را Fetch کند.
File Tenant B را Download کند.
Search Tenant B را ببیند.
این Scenarioها باید Test شوند.
Automated Tests
یکی از Testهای حیاتی:
Create Tenant A Data
Create Tenant B User
Attempt Access
Expected: Forbidden
این Testها Regression را کاهش میدهند.
Integration Test
فقط Unit Test کافی نیست.
Permission و Tenant Isolation بهتر است در Integration Test نیز بررسی شوند.
Test Data
QA باید چند Tenant واقعینما ایجاد کند.
اگر همه Testها فقط با یک Tenant انجام شوند، Cross-Tenant Bugها ممکن است مخفی بمانند.
Penetration Testing
برای SaaSهای حساس یا Enterprise، Security Assessment مستقل میتواند ارزشمند باشد.
مخصوصاً قبل از Scale یا قراردادهای بزرگ.
Audit Tenant Access
Admin داخلی Product نیز باید Access کنترلشده داشته باشد.
نباید هر Support Agent بتواند Data هر Customer را مشاهده کند.
Impersonation
بعضی Admin Panelها قابلیت Login as User دارند.
این Feature بسیار حساس است.
باید:
Permission محدود
Audit Log
Reason
داشته باشد.
Support Access
اگر Support برای Debug نیاز به Customer Data دارد، Access باید:
محدود
موقت
ثبتشده
باشد.
Privacy
SaaS باید مشخص کند چه Dataهایی جمعآوری میشوند و چرا.
Data Minimization میتواند هم Security و هم Compliance را بهتر کند.
Encryption
ارتباط Client و Server باید امن باشد.
Data حساس نیز در صورت نیاز میتواند Encryption خاص داشته باشد.
اما Encryption نباید بدون Threat Model صرفاً برای Marketing اضافه شود.
Secret Management
Credentialهای Database، Payment و API نباید داخل Source Code باشند.
Secret Manager یا Environment مناسب استفاده شود.
Backup Encryption
Backup نیز Data حساس دارد.
نباید Security Backup ضعیفتر از Database اصلی باشد.
Tenant Offboarding
وقتی Subscription پایان پیدا میکند، Lifecycle Data باید مشخص باشد.
مثلاً:
Day 0:
Read Only
Day 30:
Suspend
Day 90:
Delete
Policy باید شفاف باشد.
Data Retention
همه Data الزاماً نباید برای همیشه نگهداری شوند.
Retention Policy میتواند بر اساس نوع Data متفاوت باشد.
Enterprise Export
Customer بزرگ ممکن است قبل از خروج Full Export بخواهد.
این Requirement بهتر است از ابتدا بررسی شود.
SLA
Enterprise Plan ممکن است SLA متفاوت داشته باشد.
مثلاً Availability یا Support Response.
Architecture باید توان Monitoring SLA را داشته باشد.
Uptime
SaaS Production باید Availability مناسب داشته باشد.
اما وعده SLA باید براساس Infrastructure واقعی باشد.
Maintenance Window
اگر Maintenance برنامهریزیشده وجود دارد، User باید اطلاع داشته باشد.
در Scale بالا Rolling Deployment میتواند Downtime را کاهش دهد.
CI/CD
Deployment Automation خطای Release را کاهش میدهد.
Pipeline میتواند شامل:
Test
Build
Deploy
Migration
باشد.
Staging
تغییرات قبل از Production روی Staging تست میشوند.
این موضوع برای Migrationهای Tenant بسیار مهم است.
Migration Safety
Database Migration باید Backward-Compatible باشد تا Deployment امنتر شود.
تغییر destructive باید با احتیاط انجام شود.
Observability
برای SaaS حرفهای فقط Log کافی نیست.
Metrics و Traces نیز میتوانند کمک کنند.
مثلاً:
Request Latency by Tenant
Error Rate
Database Load
Tenant-Specific Incident
گاهی مشکل فقط یک Tenant را تحت تأثیر قرار میدهد.
Monitoring Tenant-Aware پیدا کردن Root Cause را سریعتر میکند.
معماری Multi-Tenant برای MVP
برای بسیاری از MVPهای B2B، Shared Database + Shared Schema میتواند انتخاب عملی باشد.
به شرط:
Tenant ID درست
Authorization
Test
Index
مناسب.
لازم نیست از ابتدا Separate Database برای هر Customer ساخته شود مگر Requirement واقعی وجود داشته باشد.
معماری Multi-Tenant برای Enterprise
اگر Customerهای Enterprise نیازمند:
Dedicated DB
Region
SSO
Audit
باشند، Hybrid Architecture قابل بررسی است.
این قابلیتها میتوانند در Plan گرانتر ارائه شوند.
هزینه معماری Multi-Tenant
هزینه به مواردی مانند:
Isolation Model
Permissions
Audit
Billing
Multi-Region
Dedicated DB
بستگی دارد.
هرچه Requirement Enterprise بیشتر شود Complexity افزایش پیدا میکند.
Multi-Tenancy و طراحی نرم افزار اختصاصی
اگر Product SaaS دارای Workflow و Data Model اختصاصی باشد، Multi-Tenancy باید از ابتدا در طراحی نرم افزار اختصاصی دیده شود.
اضافهکردن Tenant Isolation بعد از ساخت Product تکمشتری معمولاً بسیار دشوارتر است.
Multi-Tenancy و Web Application
Frontend نیز باید Tenant-Aware باشد.
مثلاً:
Workspace Switcher
Role
Branding
Plan
را نمایش دهد.
برای طراحی Core Product میتوانید صفحه طراحی وب اپلیکیشن آرکوتک را بررسی کنید.
ارتباط با توسعه SaaS
Multi-Tenancy یکی از Coreهای ساخت SaaS B2B است.
اگر هنوز Architecture کلی Product مشخص نشده، ابتدا مقاله توسعه SaaS را مطالعه کنید.
اشتباه اول: اعتماد به Tenant ID Front-end
Backend باید Membership را Verify کند.
اشتباه دوم: Query بدون Tenant Scope
Data Access باید Tenant-Aware باشد.
اشتباه سوم: Permission فقط در UI
Backend باید Authorization واقعی داشته باشد.
اشتباه چهارم: Cache بدون Tenant Key
میتواند Cross-Tenant Data Leak ایجاد کند.
اشتباه پنجم: File Public
File خصوصی باید Authorization داشته باشد.
اشتباه ششم: Search بدون Tenant Filter
Search Index نیز باید Tenant Isolation داشته باشد.
اشتباه هفتم: Log بدون Tenant Context
Debug را دشوار میکند.
اشتباه هشتم: Separate Database از روز اول بدون نیاز
Operations را بیدلیل پیچیده میکند.
اشتباه نهم: Custom Code برای هر Customer
SaaS را به پروژههای سفارشی متعدد تبدیل میکند.
اشتباه دهم: نداشتن Cross-Tenant Test
یکی از مهمترین تستهای امنیتی SaaS همین است.
چکلیست معماری Multi-Tenant
قبل از Launch بررسی کنید:
Tenant چگونه تعیین میشود؟
Membership چگونه ذخیره میشود؟
Data چگونه Scope میشود؟
Files Tenant-Aware هستند؟
Search Tenant-Aware است؟
Cache Tenant-Aware است؟
Queue Tenant Context دارد؟
Audit Log داریم؟
Backup Strategy چیست؟
Tenant Delete Policy چیست؟
رویکرد آرکوتک به معماری SaaS چندمستاجری
در آرکوتک، Multi-Tenancy براساس Scale واقعی و Security Requirement محصول طراحی میشود.
ابتدا مشخص میکنیم:
Tenant چیست؟
چند Tenant پیشبینی میشود؟
Data هر Tenant چقدر است؟
آیا Enterprise Customer داریم؟
Dedicated Database لازم است؟
چه Roleهایی وجود دارند؟
Billing به Tenant متصل است یا User؟
بعد مدل مناسب انتخاب میشود.
برای MVP اغلب Architecture سادهتر انتخاب میشود اما Isolation از همان نسخه اول جدی گرفته میشود.
در صورت رشد Product، میتوان Architecture را به مدل Hybrid یا Sharded توسعه داد.
هدف این نیست که SaaS از روز اول پیچیدهترین Infrastructure ممکن را داشته باشد.
هدف این است که Security Boundary درست باشد و Architecture بتواند همراه Product رشد کند.
جمعبندی
معماری Multi-Tenant یکی از مهمترین بخشهای طراحی SaaS است.
در این مدل چند Customer از یک Product استفاده میکنند اما Data و Permissionهای آنها باید کاملاً از یکدیگر جدا بمانند.
سه مدل رایج:
Shared Database
Separate Schema
Separate Database
هستند.
انتخاب بین آنها باید براساس:
Scale
Security
Cost
Operations
Enterprise Requirements
انجام شود.
برای بسیاری از SaaSهای اولیه Shared Database انتخاب مناسبی است، اما Tenant Isolation باید در تمام Layerهای سیستم از Database تا Cache، Search، Storage و Queue enforce شود.
اگر قصد ساخت SaaS B2B یا نرم افزار اشتراکی چندشرکتی دارید، معماری چندمستاجری باید از ابتدای طراحی Product در نظر گرفته شود؛ نه بعد از اینکه صدها Customer وارد سیستم شدند.
سوالات متداول
Multi-Tenant چیست؟
معماریای است که چند Customer مستقل از یک Application مشترک استفاده میکنند ولی Data هر Tenant از دیگران جدا باقی میماند.
بهترین مدل دیتابیس برای SaaS چیست؟
مدل واحدی برای همه Products وجود ندارد؛ Shared Database، Separate Schema یا Separate Database براساس Scale و Security انتخاب میشوند.
آیا Shared Database امن است؟
در صورت طراحی صحیح Tenant Isolation، Authorization و Testing میتواند امن باشد؛ ضعف در Query یا Permission میتواند Data Leak ایجاد کند.
Tenant ID چه کاربردی دارد؟
برای مشخصکردن مالک هر Record و اعمال Isolation، Permission، Reporting و Billing استفاده میشود.
آیا برای SaaS MVP باید هر Tenant دیتابیس جدا داشته باشد؟
معمولاً نه. Shared Database برای بسیاری از MVPها مناسب است، مگر اینکه Requirement امنیتی یا تجاری خاصی وجود داشته باشد.
