Cell-Based Architecture
also called Cellular Architecture
Partitioning a service into complete, independent copies of itself, each serving a subset of customers, so a failure is bounded to one cell.
A cell is a full vertical slice — its own compute, its own data store, its own queues — serving an assigned slice of traffic. Cells do not share state and, ideally, do not share a control plane on the request path. A customer is routed to exactly one.
The property this buys is bounded blast radius under any failure mode, including the ones you did not anticipate: a poison message, a bad migration, a hot tenant, a corrupted cache, an operator error. Instead of a global outage you get one cell affected, which is a fraction of customers and a smaller thing to recover.
It is the arrangement AWS writes about in the Builders' Library and that Slack and others have described adopting. It also constrains deployment usefully — releasing cell by cell makes a staged rollout the only possible rollout.
The costs are real: routing must be reliable and is itself a shared component, per-cell overhead means lower utilisation, cross-cell operations (analytics, a customer moving cells) need explicit design, and operating fifty cells requires the automation to treat them as fifty rather than as a fleet you occasionally SSH into.