SaaS Multi-tenancy: Demand-gated Architecture

چرا این تصمیم را باید «تقاضامحور» کرد؟

چندمستاجری (multi-tenancy) یک نشان افتخار SaaS نیست. اگر محصول هنوز تعداد محدودی مشتری دارد، فشار هزینه اثبات نشده، ظرفیت عملیات ضعیف است یا tenant context در تمام مسیر درخواست و داده قابل ردیابی نیست، اشتراک‌گذاری زودهنگام منابع فقط سطح شکست را بزرگ‌تر می‌کند. در این درس هدف انتخاب یک الگوی محبوب نیست؛ هدف ساختن Demand-gated SaaS Multi-tenancy Decision, Isolation & Operations Matrix v1 است تا تصمیم POOL، SILO، HYBRID_STAMP یا DEFER از روی شواهد بازسازی شود.

قاعده‌ی مرکزی: «می‌توانیم مشترک کنیم» با «الان باید مشترک کنیم» یکی نیست. قبل از promotion باید سه دروازه روشن باشند: Demand Gate، Isolation Gate و Operations/Cost Gate. اگر یکی از آن‌ها شواهد کافی ندارد، وضعیت مثبت ساخته نمی‌شود.

مرز درس و مسیر یادگیری

این درس مالک تصمیم معماری چندمستاجری و evidence package آن است. AGN-014 مالک release/support matrix است و MKN-001 مالک instructional design؛ آن outcomeها اینجا جذب نمی‌شوند. prerequisite سخت AGN-012 است و AGN-014 فقط prerequisite نرم/زمینه‌ای است.

مسیر پیشنهادی: ابتدا demand snapshot را قفل کنید؛ سپس تعریف tenant و tenant-context propagation را مشخص کنید؛ isolation requirement را بنویسید؛ سه candidate POOL / SILO / HYBRID_STAMP را با cost، scale، noisy-neighbor، blast radius و operability مقایسه کنید؛ در پایان تصمیم را فقط تا سطحی بالا ببرید که شواهد اجازه می‌دهد.

مدل ذهنی: چهار لایه، یک تصمیم

ماتریس را چهار لایه ببینید: تقاضا (تعداد فعلی، forecast، growth trigger، cost pressure)، مرز tenant و isolation (tenant context، compliance، resource sharing)، عملیات (quota، observability، onboarding، blast radius)، و اقتصاد/مهاجرت (unit cost و migration cost). تصمیم نهایی تابع هر چهار لایه است، نه فقط یک نمودار معماری.

Azure الگوهای چندمستاجری را روی طیفی از اشتراک کامل تا جداسازی per-tenant توضیح می‌دهد و deployment stamps را هم به‌عنوان راهی برای جداسازی tenant یا گروه tenantها مطرح می‌کند. AWS نیز isolation را بنیادی می‌داند اما صریحاً یک strategy واحد برای همه‌ی SaaSها تجویز نمی‌کند. نتیجه‌ی MAKNOW از این FACTها فراتر نمی‌رود: pattern خارجی authority تصمیم محلی نیست.

فیلدهای پایه‌ی ماتریس

هویت تصمیم با architecture_decision_id و demand_snapshot_id شروع می‌شود. تقاضا با tenant_count_current، tenant_count_forecast، growth_trigger و cost_pressure_signal ثبت می‌شود. سپس tenant_context_propagation_ref و isolation_requirement_ref باید نشان دهند tenant چگونه در authentication، authorization، data access، queue/job و observability حمل می‌شود و چه جداسازی‌ای لازم است.

برای عملیات، noisy_neighbor_risk، blast_radius، per_tenant_quota_ref، onboarding_automation_state و tenant_aware_observability_ref حیاتی‌اند. اگر این فیلدها UNKNOWN باشند، promotion به pooled architecture قابل دفاع نیست.

Demand Gate، Isolation Gate و Operations Gate

Demand Gate سؤال می‌کند آیا رشد/هزینه/تعداد tenant واقعاً پیچیدگی اشتراک را توجیه می‌کند. threshold یک حقیقت جهانی نیست؛ سیاست محصول باید trigger خود را قابل مشاهده کند. Isolation Gate بررسی می‌کند tenant identity و الزام‌های compliance با مدل انتخابی سازگارند. POOL برای tierای که dedicated infrastructure الزام قطعی دارد کافی نیست. Operations Gate می‌پرسد آیا quota، tenant-aware metrics/logs، onboarding automation و support model برای کنترل blast radius وجود دارد.

حتی اگر forecast بزرگ باشد، نبود tenant-context propagation یک blocker مستقل است. همین‌طور اگر tenant context عالی باشد اما unit-cost/migration-cost یا owner approval وجود نداشته باشد، تصمیم هنوز review-ready نیست. معماری مشترک فقط زمانی promote می‌شود که evidenceهای لازم با هم بسته شوند.

مثال پایه: چرا DEFER تصمیم معتبر است

محصول A اکنون 12 tenant دارد، forecast دوازده‌ماهه 24 است، فشار هزینه پایین و تیم عملیات کوچک است. tenant context و isolation requirement مستندند، اما demand trigger هنوز clear نشده و مهاجرت به shared data plane هزینه‌ی قابل توجه دارد. تصمیم درست در این fixture DEFER_SHARED_MULTI_TENANCY / DEFERRED است؛ نه چون multi-tenancy بد است، بلکه چون زمان promotion اثبات نشده. revisit_trigger مثلاً می‌تواند «forecast عبور از threshold سیاست یا افزایش cost pressure» باشد.

در mutation درس، forecast ناگهان بالا می‌رود اما tenant_context_propagation_ref همچنان موجود نیست و decision روی PROMOTE_POOL گذاشته شده است. evaluator باید HOLD_TENANT_CONTEXT_MISSING بدهد؛ تعداد tenant به‌تنهایی isolation proof تولید نمی‌کند.

Failure modeهای مهم

1. SaaS = pooled by default: اشتباه؛ SaaS model و resource-sharing model یک چیز نیستند.
2. Forecast = authority: forecast ورودی demand است، نه مجوز امنیتی.
3. Login tenant-aware ولی worker/job بی‌tenant: propagation ناقص و cross-tenant risk.
4. Noisy neighbor بدون quota: یک tenant می‌تواند ظرفیت مشترک را مصرف کند.
5. Observability بدون tenant dimension: incident را نمی‌توان به blast radius واقعی نسبت داد.
6. Pool برای regulated tier: اگر dedicated requirement قطعی است، pool خالص conflict دارد.
7. Owner approval ساختگی: UNKNOWN باید HOLD بماند، نه اینکه مدل آن را حدس بزند.

مقایسه‌ی Pool، Silo و Hybrid/Stamp

POOL معمولاً density و unit cost بهتری می‌دهد اما tenant-context و isolation control قوی‌تری می‌خواهد و noisy-neighbor/blast-radius مهم‌تر می‌شوند. SILO جداسازی و reasoning ساده‌تری می‌دهد، ولی unit cost و مدیریت deployment می‌تواند بالاتر رود. HYBRID_STAMP اجازه می‌دهد tenantهای عادی در shared stamp باشند و tierهای regulated یا high-risk روی dedicated stamp قرار بگیرند؛ در عوض control plane، mapping tenant→deployment و migration پیچیده‌تر می‌شود.

هیچ‌کدام «بهترین» نیست. خروجی خوب باید بگوید برای کدام evidence package کدام گزینه bounded است و چه triggerی تصمیم را دوباره باز می‌کند.

برای مهندس باتجربه: از pattern catalog به decision system

اگر pool/silo/stamp را می‌شناسید، بخش مهم این درس schema و gateهاست. به‌جای debate سلیقه‌ای، یک decision record بسازید که بتواند با mutationهای کوچک دوباره اجرا شود: compliance از shared به dedicated تغییر کند؛ forecast رشد کند؛ observability tenant-aware اضافه شود؛ یا migration cost دو برابر شود. اگر نتیجه بدون تغییر evidence تغییر می‌کند، evaluator deterministic نیست. اگر evidence تغییر کند و نتیجه ثابت بماند چون baseline را کپی کرده‌اید، transfer fail است.

تمرین هدایت‌شده و مستقل

ابتدا fixture پایه را اجرا کنید و توضیح دهید چرا DEFER_REVIEW_READY success state است، نه شکست. سپس فقط tenant_count_forecast و decision را به promotion تغییر دهید اما tenant-context ref را حذف کنید؛ باید HOLD بگیرید. در تمرین مستقل، یک محصول با چندصد tenant، فشار هزینه بالا، quota و tenant-aware observability بسازید اما tier regulated را dedicated کنید. از صفر تصمیم HYBRID_STAMP را بازسازی کنید و tenant-to-deployment map را مشخص کنید.

هیچ fixture نباید شبکه، cloud account، billing یا production tenant را لمس کند؛ تمام داده‌ها synthetic هستند.

چه چیزی باید قابل اثبات باشد؟

Reviewer باید بتواند بدون reasoning پنهان مدل پاسخ دهد: demand snapshot کدام است؟ tenant context کجا حمل می‌شود؟ isolation requirement چیست؟ noisy-neighbor چگونه مهار می‌شود؟ blast radius چیست؟ quota و observability tenant-aware کجا ثبت شده؟ unit/migration cost چقدر است؟ decision option/state چیست؟ چه ownerی approval داده؟ چه زمانی decision دوباره باز می‌شود؟ اگر پاسخ یکی از فیلدهای decisive UNKNOWN است، state موفق مجاز نیست.

ارزیابی و Transfer

برای transfer، baseline DEFER oracle نیست. Product B صدها tenant، cost pressure بالا، quota و observability tenant-aware دارد؛ اما tier regulated به dedicated infrastructure نیاز دارد. POOL خالص conflict ایجاد می‌کند و SILO کامل ممکن است هزینه‌ی غیرضروری بسازد. اگر tenant→deployment mapping، blast-radius controls، cost/migration evidence و approval کامل‌اند، HYBRID_STAMP می‌تواند به TRANSFER_HYBRID_REVIEW_READY برسد. اگر هر کدام missing است، HOLD حفظ می‌شود.

منابع، Fact / Inference / Design و تازگی

FACT: Azure معماری چندمستاجری را از shared تا isolated و با trade-offهای scale/isolation/cost/performance/complexity/manageability توضیح می‌دهد. FACT: AWS tenant isolation را foundational می‌داند و strategy را context-dependent توصیف می‌کند. INFERENCE: demand-gated promotion از ترکیب این trade-offها و هزینه‌ی complexity نتیجه‌گیری مهندسی MAKNOW است. DESIGN: thresholdها، success stateها، owner authority و revisit policy متعلق به MAKNOW است.

لینک AWS ثبت‌شده در Bible به مسیر قدیمی/نامرتبط اشاره می‌کرد؛ claim بدون تغییر با صفحه رسمی فعلی Tenant Isolation — SaaS Lens دوباره تأیید شد و این locator correction فقط در freshness/evidence layer ثبت می‌شود، نه با mutation Bible فریز‌شده. بازبینی بعدی حداکثر تا 2027-01-01 یا زودتر در صورت تغییر material guidance انجام می‌شود.