Multi-Tenancy in SaaS: Architecture, Isolation & Security

Choose an isolation model deliberately

Multi-tenancy is a data-security property before it is a database pattern. Shared tables, schemas per tenant, and databases per tenant can all be safe or unsafe depending on where tenant identity is established, how queries are scoped, and whether asynchronous work preserves that context.

Where tenant leaks actually happen

• Resolve tenant identity from a trusted credential or host mapping, never a writable request field alone.
• Apply tenant scope in repository/query boundaries so developers do not remember it manually on every screen.
• Cache keys, object-storage prefixes, search indexes, exports, and queues need the same isolation rules as SQL tables.
• Administrative cross-tenant operations should use separate permissions and explicit audit events.

Layered tenant enforcement

The tenant is resolved once from trusted identity, then propagated through authorization, data access, cache, files, and background messages.

A cross-tenant export test

Isolation failures worth testing

Tenant-security review

• Document the chosen isolation model and threat assumptions.
• Centralize tenant resolution and query scoping.
• Namespace cache, storage, search, and queues by tenant.
• Audit privileged cross-tenant access.
• Automate negative isolation tests across APIs and workers.