Cell Router
The thin component that maps a request to its cell, and which is the one shared dependency a cell-based architecture must keep minimal.
Cell-based architecture divides a system into independent stacks, each serving a subset of customers. A failure is contained to one cell rather than affecting everyone — blast radius reduced by construction rather than by careful operations.
The router is the exception to the isolation, because every request passes through it. It is therefore the one component that must be as simple as possible: a mapping from a partition key — customer, tenant, region — to a cell, and nothing else.
Design rules that follow: no business logic in the router; the mapping should be cacheable and changeable without a deployment; and the router must be statically stable, continuing to route on its last-known mapping if its configuration source is unavailable.
The rest of the design: cells are sized to a maximum, and growth is handled by adding cells rather than enlarging them, which keeps the failure domain bounded as the system grows. Deployments are staged cell by cell, which makes the architecture a progressive-delivery mechanism as well as an isolation one.
The costs are honest: lower utilisation, because capacity cannot be shared across cells; cell migration for a customer that outgrows its cell, which is a real operational procedure; and cross-cell operations, which are difficult by design and should be rare.