Would you rather 100% of customers see 5% errors, or 5% see 100%?
Cells choose
The second. A contained failure is easier to detect, roll back and explain. Blast radius becomes a target, like latency.
Full copies of the stack behind one thin router
Each cell owns its app and databases, capped at a tested size. The tenant ID picks the cell; cells never share state or call each other.
Cells or shards?
Bad: Shard the data
Apps, caches and deploys stay shared, so a bad build hits every shard’s users.
Good: Split the whole stack
A cell owns its apps, data and deploys; cells usually contain shards.
Every request crosses the router. Keep it thin.
- Key → cell from memory, then forward
- Control plane down? Keep the last good map
- One pool and timeout per cell
- No logic, database calls or cross-cell retries
3.6%
of others go down with a poison customer
Shuffle sharding deals each customer 2 of 8 workers: 28 possible pairs. Only 1 in 28 others share both; those sharing one retry on the other.
Ship to one cell first, then growing waves
Bake after each stage; roll back on any alarm. Caught while cell 1 of 20 bakes, a bad change reaches 5%, not 100%.
Stamps are Azure’s cells. Geodes serve anyone.
A stamp owns its tenants’ data, so each request must reach its stamp. Every geode holds all data, so the nearest one answers. Regional survival, not tenant isolation.
Remember
Map each tenant to one of N capped cells behind a thin router, and deploy in waves. A failure then reaches about 1/N of customers.