Cell-Based Architecture: Blast Radius by Design

Q: What is cell-based architecture and how does it differ from sharding?

Cell-based architecture divides a workload into multiple complete, independently deployable instances — each with its own compute, data store, cache, queues and dependencies — where every cell serves a fixed subset of customers and a failure inside one cell cannot propagate to the others. Sharding, by contrast, splits only the data tier while the application, cache and configuration typically remain shared. That difference determines which failures are actually contained. Most serious outages are not data problems: they are bad deploys, poisoned caches, configuration pushes, runaway retry storms, exhausted connection pools and hitting an account or service quota. A data shard contains none of those because the shared application tier fails identically for every shard. A cell contains all of them, because there is no shared application tier to fail. AWS positions cell-based architecture as a workload-level extension of the Well-Architected bulkhead practice, and identifies fault isolation, predictability and testability as the properties it buys. Testability is the most underrated: because a cell has a known maximum size, you can load-test it at full scale rather than extrapolating what happens at several times current traffic.

Q: How small should a cell be, and how many cells should we run?

A cell should be small enough to test at full scale and to keep any single cell failure below the customer impact you are willing to accept, and large enough to fit your biggest individual tenant while retaining reasonable economies of scale. AWS frames this as three opposing forces and gives the arithmetic plainly: with ten cells each holds about ten percent of customers, and with one hundred each holds about one percent, so the number of cells directly sets your worst-case scope of impact. Smaller cells reduce that impact, are cheaper and easier to test, and are far less likely to run into per-account or per-region service quotas, which often surface only at scale. Larger cells are easier to operate because there are fewer replicas of the workload to manage, and they utilise capacity better because idle headroom is amortised across more traffic. The decision that matters more than the specific number is defining the maximum cell size explicitly — in transactions per second, tenants supported, or throughput — and then load-testing at that ceiling so it is a measured contract rather than an aspiration. The common failure is never choosing, and allowing one cell to drift into holding most of the traffic, at which point the blast radius quietly returns to where it started.

Q: Why must the cell router stay thin, and what should never go into it?

The router is the one component that sits outside the cell boundary and therefore is not itself celled, which means its blast radius is one hundred percent of customers. Every capability you add to it takes a component that can already take the whole system down and gives it more ways to do so. AWS’s cell routing guidance states that the routing layer must remain as simple and horizontally scalable as possible, avoiding complex business logic, and must continue operating normally for other cells when one cell is unreachable. The recommended mechanism is a computationally efficient partition mapping — for example a cryptographic hash combined with modular arithmetic — or a lookup in a small, rarely changing mapping pushed to the edge. Four things in particular should never live there. Authentication, because an identity provider outage then becomes a total outage and every auth deploy carries global blast radius. Rate limiting backed by shared state, because that store becomes a shared failure domain on the request path of every cell. Cross-cell response aggregation, because the availability of such an endpoint is the product of the availabilities of the cells it touches rather than the maximum. And a live database lookup per request to resolve the cell, because the mapping store becomes a global dependency. Give the router an explicit latency budget and treat any feature that threatens it as a request to move that feature into a cell.

Q: When should you NOT adopt cell-based architecture?

Do not adopt cells when the workload has no stable partition key, and do not adopt them before deployment and provisioning are fully automated. The partition key test is the decisive one: if a meaningful share of ordinary requests must touch data belonging to more than one key, cells force those requests into cross-cell calls or distributed transactions, and the availability of a multi-cell request is the product of the cells involved rather than the best of them. Marketplaces that match arbitrary buyers to arbitrary sellers, systems that require global uniqueness checks on every write, and analytics that join across all tenants are the classic examples where the honest answer is not to cell — bulkheads, quotas and data sharding are better fits. The automation test is the second: N cells multiply every manual operational step by N. If provisioning a new environment currently takes a person a day, ten cells turn every change into ten days of drift, and a routine security patch becomes a project. There is a third, softer condition: if you have no tooling to migrate a tenant between cells or to drain a cell entirely, you will eventually face an unbalanced fleet or a degraded cell you cannot evacuate, and both erode the isolation you paid for.

Q: What is shuffle sharding and when does it apply?

Shuffle sharding assigns each customer a randomly chosen subset of workers from a larger pool, rather than a contiguous block, so that any two customers are unlikely to share their entire subset. AWS’s worked example makes the arithmetic concrete: with eight instances arranged as four traditional shards of two, a problem triggered by one customer can affect around a quarter of customers, whereas choosing two instances at random from eight yields fifty-six potential shuffle shards, sharply reducing the chance that two customers overlap completely. Extending to four instances per shard with client retries reduces exposure to roughly one in one thousand six hundred and eighty of the customer base. The technique works because the workers are interchangeable and a client that hits a bad worker can retry elsewhere, so overlap must be complete before a customer is fully affected. That precondition is also its limit. Shuffle sharding does not apply to stateful cells holding a tenant’s data, because you cannot randomly distribute one customer’s database across several cells and expect to retry your way out. The correct composition is cells for stateful tenancy and shuffle sharding for stateless front-end or worker capacity, and any architecture diagram that draws them as the same layer deserves scrutiny.

Q: How do deployments change in a cell-based system?

Deployments become wave-based, and for most teams this is the benefit that actually justifies the programme. Instead of pushing a change everywhere at once, the pipeline deploys to a single cell, bakes it against real production traffic while observing cell-level metrics, then expands to a small group of cells, then to the remainder. A defective change is therefore detected by genuine traffic on a small fraction of customers, which is a far stronger signal than any staging environment produces, and the remedy becomes draining one cell rather than rolling back the entire fleet. Two conditions make this real rather than notional. First, observability must carry a cell dimension on every metric, and alerting should fire on one cell diverging from its peers, because fleet-wide averages hide exactly the signal that cells exist to produce — a comparison that is only meaningful when cells are of comparable size, which is another argument for capping cell size. Second, the deployment pipeline must default to waves. Teams that adopt cells and then configure the pipeline to push to all cells simultaneously have paid the full operational cost of cells while retaining the blast radius of a monolith, which is the most expensive possible outcome.

Q: Do Availability Zones and multi-region deployment give the same isolation as cells?

No, they solve a different problem and the distinction matters. Availability Zones isolate infrastructure: power, cooling, networking and hardware locality events. They do nothing about your own software, because the same application build and the same configuration are deployed to every zone. A bad deploy, a poisoned cache entry, a corrupt configuration push or a code path that exhausts a shared quota fails identically in all zones simultaneously. Regions add geographic separation and contain region-wide infrastructure events, but the same logic applies to your code — a defective release rolled out globally is a global outage regardless of how many regions you occupy. Cells are the containment mechanism for failures originating in your own software and operations, which is where the majority of customer-visible incidents come from. They are also complementary rather than alternative: a mature design places cells within zones and regions, so infrastructure events and software events are each contained by the mechanism suited to them. Slack’s cellular migration is instructive here, since it was motivated by a cross-zone network failure that behaved as a gray failure, where components held conflicting views of health and automation could not converge — a scenario that required an explicit traffic-draining capability rather than zone redundancy alone.

Q: What operational tooling must exist before cells deliver value?

Four capabilities, and the programme underdelivers without any one of them. First, fully automated environment provisioning and deployment, because cells multiply every manual step by the number of cells; if creating an environment requires human intervention, the cell count becomes a tax on every change. Second, tenant migration between cells with bounded downtime, needed for rebalancing after growth, for relocating a tenant that has outgrown its neighbours, and for evacuating a degraded cell. This is usually the hardest component to build, and the worst time to start writing it is during an incident. Third, traffic draining at fine granularity — Slack set a requirement of removing traffic within five minutes at one percent increments to protect a 99.99% availability SLA, with no in-flight queries abandoned — because the practical response to a degraded cell is to move traffic away from it, and a drain capability that has never been exercised in production should be assumed not to work. Fourth, cell-dimensioned observability, so that every metric can be compared across cells and alerts can fire when one cell diverges from its peers rather than when a fleet-wide average finally moves. Together these turn a cell architecture from a diagram into an operational property.

Satyam Kumar

Back to Blog

system-design

Cell-Based Architecture: Blast Radius Is a Number You Choose

By Satyam KumarAugust 15, 202616 min read

cell-based architecture blast radius shuffle sharding fault isolation bulkhead pattern cell router multi-tenant saas resilience engineering aws well-architected availability zones deployment waves traffic draining distributed systems sre practices partition key 2026

Cell-Based Architecture: Blast Radius Is a Number You Choose

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

Cell-Based Architecture: Blast Radius Is a Number You Choose

Frequently Asked Questions

Share this article

Comments

Leave a comment