The core question: how much do tenants share?
| Model | Isolation | Cost / ops | Typical use |
|---|---|---|---|
| Silo | Highest | Highest | Regulated or enterprise-premium tiers |
| Bridge | High | Medium | Mid-market; per-tenant backup/restore |
| Pool | Logical only | Lowest | Long tail of small tenants |
Most real platforms are hybrid: pooled by default, with big tenants moved to dedicated shards.
Must-haves
- Tenant context everywhere: resolved at the edge (API key, subdomain, token) and propagated through every call, log, metric and event.
- Data isolation enforced below the app: a tenant filter injected in the repository layer, row-level security, or per-tenant DB. Never trust each query to remember
tenant_id. - Noisy-neighbour controls: per-tenant rate limits, quotas, job-queue fairness, and bulkheads.
- Per-tenant config and feature flags: plans, limits, regions (data residency).
- Fine-grained RBAC: roles scoped to tenant → space/stack → branch/environment → content type/taxonomy.
At Contentstack (500+ enterprise tenants) I owned platform architecture for Taxonomy RBAC. It's one capability, not "taxonomy plus RBAC": access is decided by where content sits in the taxonomy, in a multi-tenant, multi-branch platform. Questions every design like this has to answer: where permissions are evaluated (resolved once per request vs. pushed down into the query), how rules inherit down the term tree, and how to keep list queries fast at enterprise content volumes.
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
Related topics
Sharding & Partitioning
Split data across nodes so storage and throughput scale horizontally — choosing shard keys, range vs hash, hot spots and rebalancing.
Circuit Breaker, Retry, Timeout & Bulkhead
The resilience toolkit — fail fast, retry safely, bound waiting, and isolate resources so one slow dependency can't take down the whole system.
MongoDB at Enterprise Scale
Data modelling by access pattern, indexing (ESR rule), transactions, change streams and the operational gotchas of large multi-tenant collections.
Design: Headless CMS with Branches & Releases
My speciality — a multi-tenant content platform with Git-like branches, scheduled releases, multi-locale publishing and per-item job status.