Cell-Based Architecture

Pradeep P
2 days ago
3 min read

Series: Modern System Design · Layer 5 — Modern infrastructure

Layer 5 · Post 14 of 15

← Previous: Sidecar Pattern → Next: SLOs, SLIs, and Error Budgets

Layer 5 — Modern infrastructure · Post 113 of 119

Shard the whole system into independent cells so a bad deploy or hot shard takes down a slice, not the planet.

What you'll learn

How a cell differs from a shard, a region, and a bulkhead
Routing, blast radius, and why cells are a copy of the stack
When cells are worth the operational tax

The idea in one minute

A cell is a mostly self-contained replica of the production system — its own app fleet, stores, queues — serving a slice of traffic (users A–M, tenant ids 0–3, region eu-west plus a hash). Cells do not share the failure domain you care about: a bad deploy, a hot key, a poisoned config.

           ┌─────────┐
clients -> │ router  │ -> cell 0  (full stack)
           │ (map id)│ -> cell 1
           └─────────┘ -> cell 2

Sharding (Post 15) often splits one database. A cell splits the product. Bulkheads (Post 31) isolate thread pools inside a process. Multi-region (Post 60) is geography; cells can be inside one region (AZ-independent copies) or be the region.

AWS popularized the name; the idea is "don't run one global monolith of microservices."

Why it matters

Blast radius is an SRE number: what fraction of customers die when we fail. One Kafka cluster, one Redis, one IAM change, one schema migration that locks — that is 100% if everything shares it.

Interviews: "how do you limit a bad deploy?" — progressive delivery and cells so cell 0 eats the canary. "How do you isolate a noisy tenant?" — pin them to a cell (Post 94 at system scale).

How it works

Pick a cell key. tenant_id, user_id hash, geo. Sticky: moving a user between cells is a migration, like resharding.

Router. Edge knows the map (or a directory service). Wrong cell = wrong data. The router is a critical dependency — make it boring (DNS, a small lookup, not a clever monolith).

No shared mutable core (or as little as you can). Shared auth issuer or global lookup is common; shared primary DB is how you fake cells and keep the blast radius. A global metadata store should be CP and tiny, not "all user rows."

Deploy per cell. Roll cell 0, watch SLOs (next post), then cell 1. A broken build takes 1/N of traffic.

Data. Each cell owns its disk. Cross-cell queries are rare (directory, fan-out with a budget — Tail at Scale).

Cost. N copies of etcd, N Kafka clusters, N on-call graphs unless you platform it. Cells without automation are just N snowflake envs.

A simple example

A SaaS with 10,000 tenants. One Postgres. Tenant "HugeCorp" runs an analytical query that fills max_connections. Everyone 500s.

Cells: 8 cells by hash(tenant) % 8. HugeCorp saturates cell 5. Other cells serve. You can also pin HugeCorp to a dedicated cell (a cell of one) after they outgrow the hash slot.

A deploy of a bad index: apply to cell 0 (5% of tenants) first. Rollback one cell, not the planet.

Common mistakes

Cells that share the one Redis "for convenience." You bought the YAML, not the isolation.

Chatty cross-cell calls on the user path. You recreated a distributed monolith with extra latency.

Router as a smart orchestrator. Keep mapping data small and cached; fail closed if the map is unknown.

12 cells on day one. Start with 2–3 when blast radius hurts; the tax is real. Single-cell plus bulkheads is fine until it isn't.

Forgetting sticky sessions / cookies. User hashed to cell 2, websocket landed on cell 7.

How this shows up in real systems

AWS internal / Route 53 / many "shuffle sharding" talks: cells and blast radius.
Slack, DoorDash, Uber engineering blogs: cell or "shard of the whole stack" stories.
Kubernetes: a cluster can be a cell; one giant cluster is the anti-pattern.
Gaming / chat: "realms" and "shards" that are cells with a product name.