Topic 14.5
Multi-tenancy
In one line
Shared infrastructure, isolated tenants — the SaaS operator's architecture, with a real isolation decision.
Think of it like this
An apartment building again — many tenants share the same building infrastructure, but each family's front door lock ensures no one wanders into someone else's flat.
Key ideas
- 01
Models: silo (one stack per tenant — expensive, isolated), pooled (shared stack — efficient, isolation work), bridge (hybrid tiering).
- 02
The #1 rule: tenant_id in EVERY query AND enforced at the repository layer (not just in the UI).
- 03
Schema strategies: tenant_id column (pooled), schema-per-tenant, DB-per-tenant — cost/isolation dial per tier.
- 04
Quotas and rate limits per tenant; noisy-neighbor mitigation on shared pools.
- 05
Onboarding = provisioning (tenant row, config, shard assignment if premium) — make it a service, not a script.
- 06
Full HLD treatment lives in phase-12 → multi-tenant-saas.
- 07
Interview: 'pooled default with tenant_id enforcement, premium tenants get isolation' sums the design.
Explain without notes
The cross-tenant leak: which layer (repo/query/scoping rule) is the last line of defense?
Practice
Design the tenant model + row-level enforcement + per-tenant quota policy end to end.
Trade-offs
- ↔
Isolation is safety; pooling is money. Tier the promise per tenant and bill accordingly.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I enforce tenant scoping at the persistence layer and can tier isolation by tenant.