Cell-Based Architecture

Best Practice: Cell-Based Architecture

Cell-based architecture partitions a system into multiple independent, self-contained instances called cells. Each cell is a complete copy of the workload that serves a defined slice of traffic or customers, with its own compute, data, and dependencies. Cells do not share state, so a failure, bad deployment, or overload in one cell is contained to that cell rather than affecting the whole system. You scale by adding more cells rather than making one stack ever larger. AWS documents this as a way to reduce the scope of impact. It matters for high-availability systems where a single shared fleet means a single bad change can take everything down.

Step-by-Step Implementation Guidance

1. Define the cell boundary: a complete, independently deployable copy of the workload.
2. Choose a partition key, such as customer or region, to map requests to cells.
3. Build a thin, highly reliable routing layer that assigns traffic to cells.
4. Ensure cells share no state; each owns its own data and dependencies.
5. Size cells so that losing one removes only a tolerable fraction of capacity.
6. Deploy changes cell by cell, validating each before the next.
7. Monitor per-cell health and route around unhealthy cells.

Common Mistakes Teams Make When Ignoring This Practice

• Running one shared fleet where a single bad deploy causes a total outage.
• Letting cells share a database, reintroducing a common failure point.
• Making the routing layer complex or stateful, turning it into the weak link.
• Sizing cells too large, so losing one is still catastrophic.
• Deploying to all cells at once instead of progressively.

Tools and Techniques That Support This Practice

• DNS and load-balancer routing for cell assignment.
• Infrastructure as code to make each cell reproducible.
• Kubernetes clusters or AWS accounts as cell boundaries.
• Per-cell observability dashboards and health checks.

How This Practice Applies to Different Migration Types

• Cloud Migration: Migrate one cell at a time, limiting risk to a single slice of traffic.
• Database Migration: Move data per cell, since each cell owns an isolated datastore.
• SaaS Migration: Onboard customers cell by cell when standing up a multi-tenant platform.
• Codebase Migration: Roll a new build to one cell first and validate before fleet-wide release.

Checklist

• Define a self-contained cell boundary.
• Choose a partition key for routing.
• Build a thin, reliable routing layer.
• Ensure cells share no state.
• Size cells to limit single-cell blast radius.
• Deploy changes cell by cell.
• Monitor per-cell health and route around failures.