Multi-tenant isolation / Informed by production work
Keeping tenants apart by construction
Shared-database multi-tenancy makes a missing predicate a data breach rather than a bug. Isolation should come from where the tenant is resolved and enforced, not from remembering to filter in every query.
- 01Request
- 02Tenant resolution
- 03Scoped data access
- 04Tenant data
01 Resolve the tenant once, at the edge
The tenant is established from the authenticated request at a single entry point and carried through the request context. No downstream component accepts a tenant identifier as an ordinary parameter.
02 Enforce scope below the business logic
Scoping lives in the data-access layer so a feature cannot opt out of it. The choice between a shared schema with a tenant column, a schema per tenant, and a database per tenant trades isolation strength against operational cost.
03 Reliability: noisy neighbours are a design concern
A single tenant should not exhaust shared capacity. Per-tenant limits and separate handling for the largest tenants keep one workload from degrading the rest.
04 Trade-off: stronger isolation, heavier operations
Physical separation is the easiest to reason about and the hardest to migrate and monitor. A shared schema is cheap to run and unforgiving of a single missing predicate — which is why enforcement belongs in one layer.