Multi-tenant isolation
Silo, pool and bridge models; the isolation primitives at each layer; and how to prove to a customer that another tenant cannot see their data.
01Silo, pool and bridge
- Choose silo, pool or bridge per tier of customer and say what each costs
- Carry a verified tenant context from the token to the last query, cache key and log line
- Enforce isolation at identity, compute, data and key layers, with a database backstop
- Prove isolation to a customer with tests and logs, not a diagram
A tenant is the unit a SaaS product sells to: a company, a school, a workspace. Multi-tenancy means many tenants share one deployment. Two things can go wrong. The serious one is a cross-tenant data leak: tenant A reads, changes or infers tenant B's data. The common one is the noisy neighbour: tenant A's batch import starves tenant B of CPU or database connections. Isolation design addresses both, and the first one is a security incident that ends contracts.
There are three deployment models. Pool shares everything and separates tenants logically by a tenant ID. Silo gives a tenant its own stack: account, database, keys. Bridge mixes them, typically pooled compute over siloed data. Most products run all three, chosen per customer tier.
| Pool | Bridge | Silo | |
|---|---|---|---|
| Isolation strength | Logical: one bug in authz can leak | Data physically separate; compute shared | Strongest: separate account and network |
| Cost per tenant | Lowest; amortised | Medium | Highest; idle capacity per tenant |
| Blast radius of a bug | All tenants | Tenants on that compute | One tenant |
| Operations | One deploy, one migration | Migrations run per database | N stacks to patch, monitor and upgrade |
| Fits | Free and self-serve tiers | Mid-market | Regulated, enterprise, data residency |
| Layer | Pool primitive | Silo primitive |
|---|---|---|
| Identity | Tenant claim in every token; authz scoped by it | Separate IdP tenant or realm |
| Compute | Shared services; tenant ID in every request context | Per-tenant namespace or cloud account |
| Data | Row-level security keyed by tenant | Database or schema per tenant |
| Keys | Per-tenant DEK under a shared KEK | Per-tenant KMS key, optionally customer-managed |
| Network | Shared mesh, policy by workload identity | Per-tenant VPC |
This is an advanced module
Advanced: Security Architecture at Scale is part of the Pro pass. 4 more sections — the deep dives, the final design, follow-ups and the test — unlock with it.
Already a cyart.io or studio.cyart.io member? Your pass code is in your Studio account.
Related lessons
- Data protection: KMS, envelope encryption, tokenisationSecEng · Cloud & Platform SecurityPro
- Cryptography you actually needSecEng · Foundations of Security EngineeringFree
- Design a secrets managerHLD · Design problems: Infrastructure & dataPro
- Design a CSPM platformHLD · Design problems: cloud & runtime securityPro