architecture-descriptionestablished · high operational burden

Multi-Tenancy Patterns

Also known as: multi-tenancy, tenant-isolation, saas-patterns, shared-database

Intent

Share infrastructure across customers while isolating data, compute, and blast radius — patterns from shared DB to dedicated clusters.

Problem

SaaS must serve many tenants on shared infrastructure. No tenant should see another's data, affect performance, or bypass limits.

Forces

•Cost efficiency: share infra, not dedicated per tenant
•Data isolation: regulatory, contractual, trust
•Performance isolation: noisy neighbor problem
•Operational: deploy once, configure per tenant

Solution

✓ When to Use

•SaaS with >10 tenants
•Regulatory data isolation (GDPR, HIPAA, FedRAMP)
•Noisy neighbor risk (variable tenant load)

✗ When Not to Use

•Single-tenant (dedicated deployment)
•Very few tenants where dedicated is cheaper
•Homogeneous workloads with no isolation needs

Pros

+Cost efficiency at scale
+Single deployment, configuration-driven
+Tenant onboarding: config, not infra

Cons

−Complexity: RLS, connection pooling, migration
−Noisy neighbor: hard to eliminate completely
−Cross-tenant queries: reporting, analytics harder
−Security surface: one bug leaks all tenants

Cost Profile

Infrastructure

Low (shared) to High (dedicated)

Operational

High — tenant onboarding, migration, isolation testing

Cognitive

High — isolation model choice, failure domains

Failure Modes

RLS policy bug → cross-tenant data leak
Noisy neighbor: one tenant's load degrades others
Schema migration: partial failure → tenant inconsistency
Connection pool exhaustion: one tenant monopolizes
Backup/restore: single tenant restore in shared DB is hard

Real-World Examples

Alternatives

single-tenant
cell-based-architecture
namespace-isolation

Related Patterns

cell-based-architecture
partitioning
rate-limiting
bulkhead
rls
tenant-isolation

Competency Domains

security compliancedata statedistribution communicationeconomics evolutionreliability ops