$ loading_
Design and assess multi-tenant SaaS architecture, isolation, billing, and resilience.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "system-type-multi-tenant-saas" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/amplifier-bundle-systems-design/main/skills/system-type-multi-tenant-saas/SKILL.md 2. Save it as ~/.claude/skills/system-type-multi-tenant-saas/SKILL.md 3. Reload skills and tell me it's ready
Design a tenant isolation strategy for a B2B multi-tenant SaaS. Compare shared database/shared tables, shared database/separate schemas, and separate databases across security, cost, scalability, operational complexity, and compliance, then recommend when to use each.
A comparative analysis of isolation models with recommended architectural decisions.
We are building a SaaS on shared infrastructure. Analyze potential noisy neighbor issues including database contention, cache pressure, queue backlog, and API throttling, and propose monitoring metrics, resource isolation, and rate-limiting controls.
A noisy neighbor risk checklist plus monitoring and mitigation recommendations.
Design a per-tenant metering and billing system for a multi-tenant SaaS covering API usage, storage consumption, active users, and feature-tier subscriptions. Explain data collection, invoice generation, reconciliation, error correction, and failure handling.
A metering and billing design outlining flows, data models, and failure handling.
Patterns, failure modes, and anti-patterns for multi-tenant software-as-a-service platforms.
Every multi-tenant system lives on a spectrum between full sharing and full isolation. The choice is not one-time — most mature SaaS platforms mix models across their stack.
| Model | Description | Cost per tenant | Isolation strength | Operational complexity |
|---|---|---|---|---|
| Shared everything | Single DB, single schema, tenant_id column on every row | Lowest | Weakest — one bad query away from data leakage | Lowest until it isn't |
| Shared compute, separate data | Shared application tier, separate database or schema per tenant | Medium | Strong data isolation, shared failure domain for compute | Medium — schema migrations multiply |
| Fully siloed | Dedicated infrastructure per tenant (DB, compute, sometimes network) | Highest | Strongest — blast radius limited to one tenant | Highest — you're running N deployments |
The right answer is almost always a hybrid. Small tenants on shared infrastructure, enterprise tenants on dedicated. The boundary is driven by:
Compliance is the most common reason teams are forced up the isolation spectrum against their economic interest. Understand these constraints early:
tenant_id filtering is defensible but requires strong evidence (query audit logs, automated testing, access controls).Design for shared-everything first, but make the isolation boundary a first-class abstraction. Every data access path should go through a tenant context that can be swapped from "row filter" to "connection router" without rewriting application code. Teams that don't do this spend 6-18 months retrofitting isolation when their first enterprise customer demands it.
Data partitioning is where multi-tenancy gets real. The schema design you pick on day one will constrain your options for years.
The most common starting point. Every table has a tenant_id column. Every query includes a WHERE tenant_id = ? predicate.
What goes wrong:
tenant_id filter leaks data across every tenant. This is the single most common multi-tenant security vulnerability. Mitigate with: PostgreSQL Row-Level Security (RLS), ORM-level query interceptors that inject tenant filters, automated test suites that assert every query plan includes the tenant predicate.tenant_id, queries scan far more data than needed. Every index should be (tenant_id, ...) not (..., tenant_id).…
Design and assess enterprise integration patterns, legacy modernization, and orchestration strategies.
Review system designs with a seven-step method to surface risks and improvements.
Evaluate system designs through Unix/Linux principles for simplicity and composability.
Design or assess Azure system architectures, operations, and cloud service choices.
Design and evaluate data pipelines, streaming systems, and ETL architecture patterns.
Design offline-first edge systems with sync, conflict handling, and weak-network resilience.
Design or assess SPA architecture across routing, state, performance, and offline support.
Design and evaluate decentralized peer-to-peer architectures and core system mechanisms.
Design and assess ML training, serving, and experimentation system architectures.
Design and evaluate CLI tools and developer SDK architecture and usability.
Design and evaluate real-time collaborative systems, sync flows, and failure handling.
Design and evaluate event-driven, message-based, and asynchronous system architectures.