Cell Router

Cell-based architecture isolates failure by giving each group of customers a complete independent stack. The one thing that cannot be per-cell is the mechanism that decides which cell a request belongs to.

That makes the router the residual shared component, and if it is complex, stateful or dependent on a control plane, it reintroduces the single point of failure that the cells were built to remove.

Why it matters

The whole value proposition rests on the router. A cell architecture with a fragile router has multiplied the operational surface and kept the total-outage risk — the worst of both arrangements.

Implementation patterns

• Keep it trivially simple. A mapping from customer identifier to cell, applied at the edge. No business logic, no data access beyond the mapping, no dependency that can fail.
• Cache the mapping aggressively with an indefinite fallback, so a control-plane outage does not stop routing. The mapping changes rarely, which makes this safe.
• Make it statically stable: the failure mode is "use the previous mapping", never "fail".
• Support relocation, because customers grow and cells become unbalanced. Moving a customer between cells is a migration — replicate, verify, brief write pause, cut over, keep a rollback — and it should be routine rather than a project.
• Deploy the router itself with extreme caution, on a slower cadence than the cells, since a router change is the one change that can affect everyone.
• Roll cell-scoped changes cell by cell with automated halt conditions, which is the property the whole architecture exists to provide.

The design questions the router forces

What is the cell key? Usually the customer or tenant, and it must be resolvable from the request without a lookup in a system that could be down — which frequently means it is embedded in the authentication token or in the hostname.

What happens to cross-cell operations? Anything spanning customers — a global leaderboard, a cross-tenant report, an aggregate — needs an explicit mechanism outside the cells, and it is where the architecture's complexity concentrates.

Industry example

Platforms with extreme scheduled peaks such as Dream11 face total outages from deployments and configuration rather than from hardware, which is exactly the class cells address. The sizing decision follows from the business question — what proportion of customers can you afford to affect — which usually implies a small number of cells rather than many, since the operational multiplier is real.

Failure scenarios

• A router with business logic, which becomes a shared component that changes constantly.
• A router that consults a control plane per request, making that plane a hard dependency of everything.
• No relocation capability, so cell imbalance is permanent and every customer move is a project.
• Cross-cell operations added ad hoc, reintroducing coupling between cells.
• The router deployed on the same cadence as the cells, so a bad router change affects everyone at once.

Trade-offs

Keeping the router simple means it cannot do useful things — no clever load-based placement, no dynamic rebalancing, no request-level intelligence. That simplicity is the point and it is continuously under pressure, because every feature that "just needs a small change in the router" is individually reasonable.

The discipline is a stated list of what the router may do, with anything else refused — the same discipline that keeps an API gateway from accreting business logic, applied to a component where the consequence of failure is larger.

Interview question

"You have eight cells and a router. Tell me what happens to a request when your configuration service is completely down, and what happens when you need to move your largest customer to a different cell."