System 12.30 — Multi-tenant SaaS Platform
In one line
One codebase, many customers: isolation, tenancy models, quotas, billing, and the scaling per tenant.
Think of it like this
An apartment building where every family (customer) has their own private flat (data), but they all share the same building infrastructure — lifts, water supply, security — to keep costs down for everyone.
Key ideas
- 01
Tenancy models: serverless/silo (isolated per tenant — simple, expensive), pooled (shared, complex isolation), bridge (hybrid).
- 02
Identity: tenant in the JWT/context; EVERY query scoped by tenant_id (row-level isolation is the #1 security rule).
- 03
Schema strategy: pooled DB with tenant_id column (default) vs schema-per-tenant vs DB-per-tenant — each a cost/isolation dial.
- 04
Quotas & rate limits per tenant (10.9): the flat edge policy keyed by tenant.
- 05
Billing metering: usage events → metering store → invoices — the money plumbing of SaaS (often overlooked!).
- 06
Onboarding: provisioning a tenant = create tenant row + config + maybe shard assignment + billing profile.
- 07
Scale: pool hot tenants on shared infra, hand premium tenants dedicated shards (the 8.5 hot-partition lesson).
- 08
Interview: 'tenant_id everywhere, pooled default, premium tenants on their own shards' is a design, not a slogan.
Code & diagrams
The one line every request passes through: tenant_id, checked before anything else happens.
Explain without notes
The 200-lines bug where one tenant sees another's rows: which three controls would have stopped it?
Practice
Design the tenant provisioning + the row-level isolation + per-tenant quotas end-to-end.
Trade-offs
- ↔
Silo = perfect isolation + cost; pooled = savings + isolation engineering. Scale your answer by tenant tier.
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 can present multi-tenant SaaS with identity, isolation, quotas, and billing metering.