Pattern · seen in 3 breakdowns across 3 companies

Cell Architecture

Cell architecture splits a system into independent copies called cells, each serving some customers on its own, so a failure stays inside one cell and you grow by adding cells, not by enlarging one.

resilience

The mechanism

The pattern at its core: the customers split across several self-contained cells, so a failure is trapped inside whichever cell it starts in.

LIVE ARTIFACTTHE PATTERN, GENERALOPEN FULL SCREEN ↗

THE IDEAIn one big shared system, a single bad thing - a broken deploy, a poisoned cache, one overloaded customer - can take down everyone at once. Splitting the customers into independent cells puts a wall around each group, so a failure can only reach the cell it started in. You also grow by adding cells instead of making one cell bigger.

WHAT TO TRYTrigger a failure as one big fleet and watch it take every customer. Then switch to cells and trigger it again: the damage stops at the cell wall. More cells make each failure smaller, but each cell is one more thing to run and keep healthy.

Fail one big fleet and everyone goes down - split into cells and the same failure stops at the cell wall.

Definition

Cell architecture organizes a system as a set of independent, self-contained units called cells, each able to serve some of the customers completely on its own. Cells don't share anything important with each other, so a failure inside one cell can't spread to the others. To handle more load you add more cells rather than making any one cell bigger. Each cell is a full, small copy of the service - its own compute, storage, queues, and routing - kept small enough that a team can run and reason about it as a single unit.

The first reason to build this way: one giant system eventually spends too much of its effort just keeping itself in sync. As it grows, the housekeeping to keep every machine in step - agreeing on who is in charge, sharing status, pushing out settings - grows faster than the useful work it can do. Past a point, more of the system's capacity goes into this coordination than into serving requests. Cells cap that by never letting any one cell get big enough to reach the wall. The whole system still grows, by adding cells, while each cell stays small and manageable.

Two charts: one big fleet where coordination overhead dominates at large size; small cells each with a thin coordination slice. — As one system grows, more and more of its effort goes into keeping itself in sync instead of doing real work. Small cells keep that effort low, and you grow by adding cells instead.

The second reason is failure isolation. In one big system, a bad deploy, a poisoned cache, a corrupted index, or one badly-behaved customer can hurt everyone. With cells, the same problem only touches the cell it happened in. The blast radius - how far a single failure can reach - is limited to the customers in that one cell. This helps most when trouble comes from a single customer - a lopsided data key, an unusually heavy query, a sudden traffic spike. The cell holding that customer takes the hit, while every other cell keeps running normally.

Cells don't all have to be identical. When a few customers are very different, such as a handful of very large ones, you can give them their own cell tuned for that heavier load. In big systems, cells often differ in size, isolation, and which customers they hold. The through-line is that a cell is the unit of three things at once:

capacity - you add cells to grow
isolation - a failure stops at the cell wall
operation - the cell is the piece you run and reason about

When it applies

01One big cluster is hitting a coordination wall. It has grown so large that adding more machines to it barely helps, because so much of its effort goes into keeping itself in sync.

02Some customers need their own setup. A few very large ones, or ones with strict data or reliability rules, are worth a dedicated cell rather than a promise you have to keep for everyone.

03Losing some customers is survivable, losing all of them is not. You can accept an incident that takes down one cell, but not one that takes down every customer at once.

04You want to roll out changes one cell at a time. Upgrades, config changes, and capacity additions can be tried on a single cell and checked before they reach the rest.

05A single component is near its ceiling. When one search cluster, database, or queue is close to its known limit, the plan is to run many small ones instead of one giant one.

Tradeoffs

There are many more things to run. Splitting a few big clusters into cells turns them into many small ones, each needing its own monitoring, alerting, and capacity planning, so the team runs a lot of them at once.

Work that spans cells gets expensive. Anything that has to reach across all cells, like global search or company-wide reports, needs a separate layer to gather the results, or you give it up. Cells work best when the work rarely crosses.

Deciding which customer goes in which cell is hard. Random placement is fair but may not balance the load; placing them on purpose works better but is ongoing work, and moving a customer between cells is its own job.

You pay more when cells are sized for their own peaks. A small cell has less spare room for a traffic spike than one big shared pool would, so you carry a higher steady-state cost in exchange for the isolation.

The same move, 3 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Discord

Discord Engineering

2025

The 2025 redesign groups smaller Elasticsearch clusters into logical cells, each dedicated to one use case (guild messages, user DMs, Big Freaking Guilds). The basic unit shifts from 'cluster' to 'cell of clusters', which isolates failures at a more useful size and lets each cell be tuned for its own job. In Discord's version the cells map directly to distinct use cases, and the BFG cell is a clean example of giving one outlier class its own cell. Read the breakdown →

Slack

Slack Engineering

2023

Slack's cells are availability zones: every service present in every AZ, no service talking across AZ boundaries, so each AZ is an independently drainable unit. The recurrence with Discord — whose cells are small Elasticsearch clusters behind application routing — is the pattern proving its generality: the cell is whatever unit you can afford to lose, sized so that losing it is routine. Read the breakdown →

Shopify

Shopify Engineering

2018

The plainest statement of the pattern on the site: shops partitioned into pods, each a fully isolated slice of the platform, with every unit of work assigned to exactly one cell so that serving a request needs one cell online. Second company — Slack's cellular architecture drains traffic away from a sick cell; Shopify's pods go further upstream and make cross-cell work structurally impossible. The shared lesson: a cell's failure has nowhere to spiral because nothing spans cells. Read the breakdown →

Often used together

Patterns sharing breakdowns with this one — derived from co-occurrence, threshold ≥2 shared.

fault-isolation ×3 generic-mitigation ×2

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.

Blast radius scales with cluster sizeDISCORD · SHOPIFY →Gray failure defeats automatic detectionSLACK →