Cell

Instead of one large deployment serving everyone, a cell-based architecture runs many complete copies of the stack, each with its own compute, data, cache and — ideally — its own control plane. Cells do not share state and do not call each other. A thin routing layer maps each customer to a cell.

The point is not efficiency; a cell architecture is measurably less efficient than a single large deployment. The point is that no single failure can affect everyone, because there is no component that everyone depends on.

Why it matters

Effort spent predicting specific failures has sharply diminishing returns — the next outage will have a cause nobody enumerated. Effort spent bounding the consequences of an unspecified failure pays off regardless of the cause, which makes it the more robust investment.

Cells also make growth predictable. A cell has a tested maximum capacity established by load-testing it to destruction; growth adds cells rather than pushing a single system further along a curve nobody has measured. This eliminates the entire "we have never run at this size" category of failure, which is a large fraction of the incidents at fast-growing organisations.

Implementation patterns

• Complete independence: no shared database, no shared cache, no cross-cell calls. A single shared component reintroduces a global failure domain and nullifies the design.
• A control plane per cell where possible, since a shared control plane is the residual single point of failure and is frequently what fails.
• The routing layer as the simplest possible component: a cached, rarely-changing mapping that fails static, serving from its cached copy when the mapping store is unavailable.
• Cell size bounded by two constraints — small enough that losing one is tolerable and it can be load-tested in full, large enough to hold the largest single tenant with headroom. The largest tenant is usually the binding constraint.
• Deployment cell by cell with health gates, so a defect that survived testing affects one cell.
• Shuffle sharding on top, assigning each tenant a random subset of cells so that one tenant's behaviour rarely affects any other tenant completely.
• Tenant migration designed from the start — copy, verify, brief write pause, routing switch, rollback by routing switch. Retrofitting it is a project, not a task.
• Per-cell observability with cross-cell aggregation, so a single degraded cell is visible rather than averaged away.

Industry example

Cell-based architecture is a documented AWS practice and underpins the resilience posture of several of its services, where the explicit goal is that an operational event affects a bounded fraction of customers rather than a region's entire population.

The counter-example is equally instructive. Roblox's 2021 outage ran approximately 73 hours because a single service-discovery and configuration cluster served the entire fleet — one shared component whose degradation under contention became a total outage with no partial-failure mode available. The subsequent work explicitly included moving toward cellular isolation, which is the standard response to that class of finding.

Failure scenarios

• A shared component — one database, one queue, one identity service, one config store — which restores a global blast radius.
• A complex shared control plane, relocating rather than removing the single point of failure.
• Cells too large, so losing one is still a major incident.
• Cells too small, fragmenting capacity and multiplying operational overhead beyond what automation can absorb.
• A tenant larger than a cell, with no plan for it.
• No tenant migration capability, so cells cannot be rebalanced as tenants grow.
• Routing that fails closed when the mapping store is unavailable, making the simplest component the outage.
• Deploying to all cells simultaneously, which discards the primary benefit of the structure.

Trade-offs

Cells cost efficiency and operational overhead. Capacity is fragmented so utilisation falls; each cell needs its own everything; and operating fifty cells requires automation mature enough that it is not fifty times the work. An organisation that adopts cells without that automation has made its operations worse.

There is also a real cost in cross-cell functionality. Anything that must span customers — global search, aggregate reporting, cross-tenant features — becomes genuinely harder, and the answer is usually a separate system fed asynchronously from all cells, which is more architecture.

The trade is efficiency, operational overhead and cross-cell complexity in exchange for a bounded worst day. The deciding question is whether a total outage is survivable for the business. Where it is not, the efficiency loss is simply the price of continuing to exist, which moves the argument from engineering preference to business constraint.

Interview question

"We want to move to cells. Tell me what our first cell boundary should be, how big a cell should be and why, and then tell me which three things in our current architecture would still be shared afterwards — and what you would do about the worst of them."