You are asked to make a multi-tenant SaaS resilient to "any single failure". You propose cells. What must you find before that claim is true?

What must be found: every shared dependency

A cell is isolated only if nothing inside it depends on something shared with another cell. The work of adopting the pattern is almost entirely the audit that finds those, and they are rarely on the architecture diagram.

The list to walk, in the order they are usually discovered:

The obvious ones — a shared database, a shared cache cluster, a shared message broker.

The infrastructure ones — a shared Kubernetes cluster (a control plane failure or a bad node pool takes every cell), a shared load balancer, a shared NAT gateway, a shared DNS zone.

The platform ones — a shared configuration service (a bad config push reaches every cell simultaneously, which is the failure cells most need to contain), a shared secrets store, a shared feature-flag service, a shared identity provider.

The pipeline ones — a single deployment pipeline that can push to all cells at once, which reintroduces global blast radius through the most common cause of incidents.

The data ones — a shared reference dataset, a shared ID generator, a shared schema registry.

The routing layer itself — which by definition spans cells and is therefore the one component whose failure is global. It must be simple, statically stable, and independently deployable.

What isolation actually buys once that is done

Containment of failures whose mechanism you did not predict: a poison message, a bad migration, a corrupted cache, an operator error, a code path only one tenant triggers. That is the class of failure that zones and regions do not contain, and it is a large share of real incidents.

Plus two operational benefits: deployment becomes inherently staged, and "drain the cell" becomes a generic mitigation applied without diagnosis.

The honest caveats

"Any single failure" is still too strong. The routing layer, the control plane you deploy through, and the identity provider remain global unless separately addressed. Per-cell overhead lowers utilisation. And cross-cell operations — analytics, moving a tenant between cells, a global search — need deliberate design rather than being discovered later.

What a strong answer adds

Proposing that the configuration and deployment paths be cell-aware from the start, since the most common global outage in a celled architecture is a change pushed to every cell at once. Cells constrain the runtime; they do not constrain a pipeline that ignores them.