What is a Cell?
A Cell is a complete, independent, self-contained instance of your entire service stack. It is not a microservice — it is a full vertical slice of your application. Each cell contains everything it needs to serve its assigned customers: its own load balancer, compute fleet, message queues, caches, and database. No cell shares infrastructure with another cell.
Instead of one giant stack handling 1,000,000 customers, you might have 20 independent Cells, each handling 50,000 customers. If Cell 4 catches fire — bad deployment, corrupted data, runaway process — the other 19 cells continue operating without interruption.
The Router
A thin Cell Router (also called a Partitioner or Routing Layer) sits in front of all cells. Its only job is to answer one question: "Which cell owns this customer?" It maintains a mapping table — typically a fast key-value store — that maps a stable customer identifier to a cell assignment.
Request: "User 123 wants to login."
Router lookup: User 123 → Cell 4
Action: Forward request to Cell 4's load balancer.
The router itself must be extremely simple and highly available. It should have no business logic, no database writes, and no dependencies on the cells it routes to. A router that goes down takes all cells offline, so it is the one component you over-engineer for reliability.
Benefits
- Blast Radius Containment: A bad deployment to Cell 4 affects only the ~5% of users assigned there. Users in Cells 1–3 and 5–20 notice nothing.
- AWS Service Limit Avoidance: AWS imposes per-account and per-region limits (Lambda concurrency, DynamoDB throughput, EC2 instance counts). Cells let you scale horizontally by adding new cells rather than hitting the ceiling of a single cell. Each cell can even live in a separate AWS account.
- Safe Deployments: You can canary a risky change to Cell 1 only, monitor error rates for 30 minutes, and then roll forward to the remaining 19 cells — or roll back with zero impact to 95% of users.
- Fault Isolation by Design: A cell cannot affect another cell because they share no infrastructure. There is no shared database connection pool to exhaust, no shared queue to back up, no shared cache to poison.
Cell Sizing and Assignment Strategy
Cells are typically sized to handle a fixed maximum load — say, 100,000 users or 10,000 requests per second. When a cell approaches capacity, you provision a new cell and migrate new customer sign-ups there. Existing customers stay in their original cell.
Customer-to-cell assignment is done at onboarding and stored in the routing table. The assignment is permanent unless you explicitly run a migration job. This "stickiness" is intentional — it ensures a customer's data always lives in one place.
Interviewers often ask: "How is cell-based architecture different from microservices?" The key distinction is scope. Microservices decompose a system horizontally by function (auth service, payment service, notification service). Cells decompose a system vertically by customer partition — each cell contains all the microservices needed to serve its customers. You can have cell-based architecture and microservices inside each cell simultaneously.