Multi-tenancy
Serving many customers from shared infrastructure while guaranteeing that no tenant can read, modify or exhaust another tenant's data or resources.
Multi-tenancy is a spectrum of isolation: silo (separate accounts, databases or clusters per tenant), pool (shared everything, tenant ID on every row) and bridge (shared compute, separate data stores). Stronger isolation costs more and is slower to operate; weaker isolation makes every authorisation bug a cross-tenant breach.
In pooled designs the tenant ID must come from the authenticated context, never the request body, and be enforced in one place: row-level security, a scoped repository layer, or per-tenant encryption keys. Noisy-neighbour limits (quotas, rate limits) matter as much as data isolation.
Interviewers probe the blast radius: what happens if one tenant's credentials leak, or one query forgets the tenant_id filter? Strong answers combine defence in depth (tenant-scoped tokens, RLS, per-tenant KMS keys) with tests that try cross-tenant access on every endpoint.
Learn it properly
Also used in
- Building AI features into security platformsSecEng · AI, vibe coding & logic structuringFree
- Design an authorisation engine (RBAC + ABAC)LLD · Problems: Access controlFree
- Authorisation models: RBAC, ABAC, ReBACSecEng · Identity & Access EngineeringPro
- Data protection: KMS, envelope encryption, tokenisationSecEng · Cloud & Platform SecurityPro
- Running security design reviews at scaleSecEng · Advanced: Security Architecture at ScalePro