Cell-Based Architecture
Scale and contain failures by placing users and dependencies into repeatable, mostly independent slices.
2–5 minute refresher
Timeout→Backoff→Jitter→Retry budget→Circuit breaker→Load shedding
Build a small complete system, stamp it out, and route each tenant to one bounded failure domain.
30second
refresher
refresher
A cell is a repeatable slice of the service stack serving a bounded tenant or key cohort. Cells limit failure impact, make capacity incremental, and provide a unit for deployment, evacuation, and compliance.
What problem does it solve?
Large shared fleets turn bad releases, overload, corrupted state, and dependency failure into global incidents. Scaling the same shared tier increases both capacity and blast radius.
How it works
- Define the tenant or key placement unit.
- Bundle compute, queues, caches, and data ownership into a cell.
- Route through a stable placement directory.
- Keep cell-local failures and deployments independent.
- Design evacuation and rebalancing as explicit workflows.
Decision guide
Key trade-offs
| Choice | What you gain | What it costs |
|---|---|---|
| Small cells | Smaller blast radius | More operational objects |
| Shared services | Lower cost | Hidden cross-cell coupling |
| Tenant pinning | Clear ownership | Hot-tenant imbalance |
What happens if?
The global control plane becomes the data plane
Every request synchronously queries the placement service. Its outage now stops every cell. Cache placement with epochs and keep existing routes operating during control-plane failure.
Where it appears
- Large SaaS platforms
- Regional services
- Regulated workloads
- AI serving fleets
Senior interview modeWhat makes a cell different from an availability zone?Show answer
A zone is infrastructure geography. A cell is an application isolation and ownership boundary that may span zones. Multiple cells can exist in one region, each with bounded tenants, data, and capacity.