# Cheat Sheet: Multi-Tenancy on One Page — Multi-Tenant SaaS Architecture

Source: https://www.skillbyai.com/en/multi-tenant-saas/mt-cheat-sheet

> Revise the core vocabulary, isolation patterns and guard rails of multi-tenant SaaS in a single pass before an exam or interview.

## Vocabulary and models

**Tenant**: a customer organisation with isolated data, users and settings. **Membership**: `(tenant_id, user_id, role)`; one person can belong to many tenants. **Control plane**: onboarding, catalogue, plans, billing, metering, offboarding. **Application plane**: the product serving requests. **Tenancy models**: *silo* (dedicated resources, strong isolation, cost grows with tenant count), *pool* (shared everything, cheapest, isolation in code and policies), *bridge* (mix per layer). **Data patterns**: database per tenant, schema per tenant, shared tables with `tenant_id`. **Catalogue**: maps each tenant to plan, placement, region and schema version, so moves are data changes. **Sharding**: tenant id as the shard key; directory placement with optional hash fallback. **Tiering**: free and small tenants pooled, enterprise tenants siloed, same code everywhere. Remember the guiding principle: share as much as possible, isolate as much as necessary, and always look placement up instead of assuming it.

## Guard rails checklist

**Identity**: resolve the tenant at the edge, verify membership from signed claims, fail closed on unknown tenants. **Context**: set once per request, isolate per task or thread, copy `tenant_id` into every queued message. **Data**: `tenant_id` leading in keys and indexes, composite foreign keys, per-tenant uniqueness, RLS with a non-owner role and `FORCE`, `SET LOCAL` or `set_config(..., true)` behind pools. **Other stores**: tenant-prefixed cache keys, scoped search, tenant-prefixed object paths. **Testing**: two-tenant isolation tests on every endpoint; answer 404 for other tenants' ids. **Fairness**: per-tenant rate limits, quotas, fair queues. **Lifecycle**: idempotent provisioning, expand-and-contract migrations in waves, suspension, export and verifiable deletion. **Business**: central entitlement checks, idempotent usage events. **Security**: per-tenant keys and crypto-shredding, regional cells for residency, audit logs and controlled impersonation. **Operations**: tenant-tagged logs and traces, careful metric cardinality, cost per tenant.

## The course in one picture

Revise in this order: choose a tenancy model, resolve and propagate the tenant, isolate the data, keep tenants fair and scalable, then operate them through their lifecycle.

![Five stages in a row: tenancy model, tenant identity and context, data isolation, fairness and scaling, lifecycle operations.](assets/figures/multi-tenant-saas/section-11-map.svg) — Figure 11.1: tenancy model -> tenant identity -> data isolation -> fairness and scale -> lifecycle operations

## Answer with trade-offs

Exam and interview answers on SaaS architecture score higher when they name the trade-off: "pool is cheaper and simpler to operate, but isolation depends on every query, so I would add RLS and isolation tests." One-word answers like "use silo" sound memorised.

**Quiz:** Which combination gives defence in depth for a pooled PostgreSQL database?

- [ ] Random UUIDs for ids and nothing else
- [x] Scoped repositories, RLS enforced for a non-owner app role, and two-tenant isolation tests
- [ ] A tenant id header sent by the browser
- [ ] A superuser connection with careful code review

*Answer:* Scoped repositories, RLS enforced for a non-owner app role, and two-tenant isolation tests. Each layer catches what the others miss: repositories make the safe path easy, RLS catches forgotten filters, tests prove it. Ids, client headers and superusers do not enforce isolation.