Multi-tenancy

Designing SaaS systems that serve many customers from shared infrastructure: tenancy models from shared tables to dedicated stacks, tenant isolation for data and security, noisy neighbours, per-tenant limits, cells, enterprise requirements and tenant-aware operations.

Reading is half of it. See this used in a real interview: walk through Design Slack →

Most B2B products serve thousands of customer organisations (tenants) from one system. Slack workspaces, Shopify stores and Salesforce orgs all share infrastructure while each customer expects its data to be private, its performance unaffected by others, and sometimes its own region or encryption keys. Multi-tenancy questions test isolation, fairness and operations, and they come up whenever a design says "for businesses".

Tenancy models

Most systems use shared tables for the long tail of small tenants and offer dedicated resources to the largest or most regulated customers. Choosing the model per tier is a reasonable interview answer.

Data isolation

With shared tables, a missing WHERE tenant_id = ? leaks one customer's data to another, the worst bug a SaaS company can have. Defences in depth:

• Tenant id in every key and every index, leading the primary key ((tenant_id, id)), which also co-locates a tenant's data.
• Enforce in one place: a data-access layer that injects the tenant filter, or database row-level security policies.
• Tenant from the token, never from a request parameter the client controls. See security and auth.
• Per-tenant encryption keys for enterprise customers, which also enables deleting a tenant by destroying its key. See encryption and key management.
• Tests that try to read across tenants.

Caches, search indexes, object storage paths, queues and logs need tenant scoping too.

Partitioning by tenant

Sharding by tenant id keeps each tenant's queries on one shard and makes tenant moves possible. The problem is skew: one giant tenant can outgrow a shard. Options: place big tenants on dedicated shards, split them by a secondary key, or use a directory that maps each tenant to its shard so it can be moved. See sharding and partitioning.

Noisy neighbours

One tenant's import job or traffic spike should not slow everyone else. Tools:

• Per-tenant rate limits and quotas on API calls, storage, jobs and concurrent connections. See Design a Rate Limiter.
• Fair queuing: background job and stream workers take work round-robin across tenants instead of first-in-first-out, so one tenant's million jobs do not block others. See Design a Job Scheduler.
• Per-tenant resource accounting (CPU, queries, storage) to spot heavy users and bill accurately.
• Isolation of heavy tenants onto separate pools once they cross a threshold. See hot keys and skew.

Cells

A cell architecture splits the system into independent copies (cells), each serving a subset of tenants with its own databases and services. A bug or overload affects one cell's tenants, not everyone, and capacity grows by adding cells. A thin routing layer maps tenants to cells. Slack, AWS and many large SaaS companies use cells to limit blast radius. See Design Slack.

Enterprise requirements

Large customers ask for:

• Data residency: their data in a specific region. See privacy and data deletion.
• Customer-managed keys, audit logs, SSO and SCIM provisioning.
• Dedicated capacity or single-tenant deployments at a higher price.
• Custom limits and SLAs. See SLIs, SLOs and error budgets.

Design the tenant model so these are configuration per tenant, not forks of the codebase.

Tenant-aware operations

• Metrics, logs and traces tagged with tenant id, so "is it just this customer?" is one query.
• Feature flags and rollouts targeted by tenant.
• Tenant lifecycle: provisioning, plan changes, moving between shards or cells, export and deletion.
• Cost per tenant to understand margins.

In the interview

When the product serves businesses, state the tenancy model, show tenant_id leading your keys, name how isolation is enforced, and mention per-tenant limits and fair scheduling. For large scale, add cells to limit blast radius.

Checklist

• Tenancy model chosen per tier: shared for most, dedicated for the largest.
• Tenant id leading every key; enforcement in one layer or with row-level security.
• Tenant derived from the authenticated identity.
• Per-tenant quotas, fair queuing and resource accounting.
• Cells or tenant directories for blast radius and moves.
• Residency, keys and audit as per-tenant configuration.