Problem
Monolithic deployment: single failure (bad deploy, AZ outage, bug) takes down entire system. Blast radius = 100%.
architecture-descriptionemerging · high operational burden
Cell-Based Architecture Patterns
Also known as: cell-architecture, failure-domain, availability-zone, cell-based
Intent
Partition system into independent cells (tenants, regions, shards) so failure in one cell doesn't affect others, enabling safe deployments and blast radius control.
Forces
- •Need to limit blast radius of failures
- •Deployments should be safe: rollout to one cell first
- •Regulatory: data residency per region
- •Capacity: add cells horizontally
Solution
✓ When to Use
- •High availability requirements (99.99%+)
- •Regulatory data residency
- •Large-scale SaaS (1000+ tenants)
- •Safe deployment: canary per cell
✗ When Not to Use
- •Small systems (<10 cells)
- •Strong cross-tenant consistency needed
- •Team not ready for operational complexity
Pros
- +Blast radius = 1 cell (1/N of tenants)
- +Safe deployments: progressive rollout
- +Independent scaling per cell
- +Data residency by cell location
Cons
- −Operational overhead: N deployments, N databases
- −Cross-cell operations: complex, eventually consistent
- −Global features: schema changes, migrations harder
- −Capacity fragmentation: uneven tenant distribution
Cost Profile
Infrastructure
High — redundant infra per cell
Operational
High — cell lifecycle, migrations, monitoring
Cognitive
High — cell routing, data placement, failure domains
Failure Modes
Control plane down → can't route, can't deploy
Cell imbalance: some cells overloaded, others empty
Cross-cell dependency: cascade failure
Schema migration: partial rollout, version skew
Real-World Examples
Alternatives
- multi-az
- tenant-isolation
- partitioning
- availability-zone
Related Patterns
- tenant-isolation
- partitioning
- leader-election
- deployment-strategy
- blast-radius
- multi-tenancy-patterns
Competency Domains
reliability opsdistribution communicationdata stateeconomics evolutionsecurity compliance