Cell-based architecture
Tenants shuffle-sharded into self-contained cells behind a thin router — a bad deploy or poison tenant takes out one cell, never the fleet.
What this design does
Instead of one big system that fails for everyone at once, the fleet is divided into identical self-contained cells, each with its own compute and data. A deliberately thin router maps tenants to cells from a cached table — and thanks to shuffle sharding, each tenant lands on a small random subset, so even a poison tenant or a bad cell only touches its shuffle-set. The control plane provisions cells asynchronously; the data plane keeps serving even if the control plane dies. This is how AWS-scale services cap their blast radius.
The patterns it composes
- Cell-based architecture — identical isolated stacks — the unit of blast radius AND of capacity
- Shuffle sharding — each tenant maps to 2 of N cells; overlap between any two tenants is tiny
- Control-plane / data-plane separation — provisioning logic never sits on the request path
- Static stability — the router serves from its cached routing table even with the control plane down
- One-box canary (cross-ref) — deploys roll cell by cell — cell 1 bakes before cell 2 sees the release
Import it, attach your own numbers, and verify the design against failures — or read the engineering notes.