# Multi-Tenancy Architecture: Low-Level Design

Source: https://www.techinterview.org/post/3233473385/lld-multi-tenancy-design/
Updated: 2026-04-18 · techinterview.org

Multi-tenancy is an architecture where a single application instance serves multiple customers (tenants), with each tenant's data isolated from others. Designing multi-tenancy correctly is one of the foundational decisions in SaaS architecture — the choice made early is expensive to change later and affects security, scalability, and operational complexity at every layer of the stack.

## Tenancy Models

### Silo (Database per Tenant)

Each tenant gets a dedicated database instance. Complete isolation: a noisy tenant cannot affect others, a breach of one database does not expose other tenants, and tenant databases can be scaled independently. Downside: operational cost scales linearly with tenant count — 1000 tenants means 1000 database instances, each requiring backups, monitoring, and patching. Best for: enterprise SaaS where tenants pay for dedicated infrastructure, strict compliance requirements (HIPAA, FedRAMP), or tenants with highly variable load patterns.

### Pool (Shared Database, Separate Schema)

All tenants share a database server but each gets a separate schema (or schema prefix). Queries stay within a schema; a connection pool routes to the correct schema per request. Isolation is logical rather than physical — a SQL bug could cross schema boundaries, but most ORMs prevent this with schema-level configuration. Better resource utilization than silo: 1000 tenants on one database server. Suitable for mid-market SaaS with moderate per-tenant load.

### Pool (Shared Database, Shared Schema)

All tenants share tables, with a tenant_id column in every table. Every query must include WHERE tenant_id = ? — a "forgotten WHERE clause" leaks data across tenants. This is the most resource-efficient model and the most dangerous: data isolation relies entirely on application-level filtering. Mitigate with Row-Level Security (RLS) in PostgreSQL — define a policy that enforces tenant_id filtering at the database level, making it impossible to query without the filter. Best for high-volume SMB SaaS where operational efficiency matters most.

## Tenant Identification

How the application knows which tenant a request belongs to: subdomain routing (acme.app.com extracts "acme"); custom domain mapping (acme.com → tenant_id lookup in DNS/config table); JWT claims (tenant_id embedded in access token); path prefix (/org/acme/resource). Subdomain is most common for web SaaS. Store the mapping in a tenant registry service: domain → tenant_id, with caching (Redis) to avoid a DB lookup on every request.

## Data Isolation Enforcement

For shared-schema tenancy, enforce isolation at multiple layers: (1) PostgreSQL RLS policy: CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.tenant_id')::uuid); SET LOCAL app.tenant_id = ? at connection time. (2) ORM-level tenant scoping: all queries go through a base repository that injects WHERE tenant_id = current_tenant. (3) Integration tests: verify that a request authenticated as tenant A cannot access tenant B's data by attempting cross-tenant fetches and asserting 404/403.

## Noisy Neighbor Problem

In shared models, one tenant generating heavy load degrades performance for all others. Mitigate with: per-tenant rate limiting (token bucket per tenant_id at the API gateway), per-tenant query timeouts (SET statement_timeout per connection), connection pool limits per tenant, and workload isolation (move heavy analytics queries to read replicas). For severely noisy tenants, offer a migration to the silo model — enterprise pricing that covers dedicated infrastructure.

## Schema Migrations

Shared-schema migrations are straightforward — one migration runs once. Separate-schema migrations must run for every tenant schema — 1000 tenants means 1000 ALTER TABLE statements. Run with parallelism but with circuit breakers: if migration fails on tenant 50, stop and investigate before proceeding. Use a migration tracking table per tenant schema to enable idempotent reruns. Separate-schema migrations are the main operational pain of the pool-with-schema model.

## Tenant Onboarding and Offboarding

Onboarding: provision tenant record, run schema migrations (for separate-schema), configure DNS (for subdomain model), initialize default data. Automate fully — manual onboarding at 1000 tenants/month is not viable. Offboarding: export tenant data (data portability, required by some regulations), archive or delete all rows (GDPR erasure), deprovision DNS and infrastructure. Model onboarding/offboarding as a state machine: pending → provisioning → active → suspended → terminated. Each state transition is logged for audit.

See also: [Meta Interview Guide 2026: Facebook, Instagram, WhatsApp Engineering](https://www.techinterview.org/post/3233460272/meta-interview-guide-2026-facebook-instagram-whatsapp-engineering/)

See also: [Uber Interview Guide 2026: Dispatch Systems, Geospatial Algorithms, and Marketplace Engineering](https://www.techinterview.org/post/3233460273/uber-interview-guide-2026-dispatch-systems-geospatial-algorithms-and-marketplace-engineering/)

See also: [Netflix Interview Guide 2026: Streaming Architecture, Recommendation Systems, and Engineering Excellence](https://www.techinterview.org/post/3233460274/netflix-interview-guide-2026-streaming-architecture-recommendation-systems-and-engineering-excellence/)

See also: [Scale AI Interview Guide 2026: Data Infrastructure, RLHF Pipelines, and ML Engineering](https://www.techinterview.org/post/3233460275/scale-ai-interview-guide-2026-data-infrastructure-rlhf-pipelines-and-ml-engineering/)

See also: [LinkedIn Interview Guide 2026: Social Graph Engineering, Feed Ranking, and Professional Network Scale](https://www.techinterview.org/post/3233460278/linkedin-interview-guide-2026-social-graph-engineering-feed-ranking-and-professional-network-scale/)

See also: [Airbnb Interview Guide 2026: Search Systems, Trust and Safety, and Full-Stack Engineering](https://www.techinterview.org/post/3233460279/airbnb-interview-guide-2026-search-systems-trust-and-safety-and-full-stack-engineering/)

See also: [Databricks Interview Guide 2026: Spark Internals, Delta Lake, and Lakehouse Architecture](https://www.techinterview.org/post/3233460280/databricks-interview-guide-2026-spark-internals-delta-lake-and-lakehouse-architecture/)

See also: [Anthropic Interview Guide 2026: Process, Questions, and AI Safety](https://www.techinterview.org/?p=3233460282)

See also: [Atlassian Interview Guide](https://www.techinterview.org/post/3233459919/atlassian-interview/)

See also: [Coinbase Interview Guide](https://www.techinterview.org/post/3233459920/coinbase-interview/)

See also: [Shopify Interview Guide](https://www.techinterview.org/post/3233459924/shopify-interview/)

See also: [Snap Interview Guide](https://www.techinterview.org/post/3233459923/snap-interview/)

See also: [Lyft Interview Guide 2026: Rideshare Engineering, Real-Time Dispatch, and Safety Systems](https://www.techinterview.org/post/3233460306/lyft-interview-guide-2026-rideshare-engineering-real-time-dispatch-and-safety-systems/)

See also: [Stripe Interview Guide 2026: Process, Bug Bash Round, and Payment Systems](https://www.techinterview.org/post/3233460268/stripe-interview-guide-2026-process-bug-bash-round-and-payment-systems/)