Cheat Sheet: Multi-Tenancy on One Page

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.

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.

Quick check: Which combination gives defence in depth for a pooled PostgreSQL database?

• Random UUIDs for ids and nothing else
• 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