Defining the Cell

The Stamp

Think of a cell like a franchise restaurant location. Each location has its own kitchen, its own staff, its own inventory, and its own customers. If the kitchen at one location catches fire, the other locations keep serving food. The franchise owner (your router) knows which location each customer should visit.

In software terms, a Cell is a complete, deployable instance of your service stack. It should be:

1. Self-Contained: It has everything it needs to process a request end-to-end — compute, storage, caches, queues. No cross-cell calls for the critical path.
2. Finite: It has a defined maximum capacity. For example: "One cell handles at most 10,000 active users." When a cell approaches capacity, you provision a new one rather than scaling the existing one.
3. Disposable: If a cell behaves badly — runaway CPU, memory leak, corrupted state — you can drain traffic from it, quarantine it, or terminate it entirely without affecting any other cell.
4. Independently Deployable: You can push a new version of your service to Cell 1 as a canary, observe its behavior, and only then roll it to Cells 2 through N. This makes cells a natural unit of progressive delivery.

The Partition Service (Router)

To make this work, you need a thin, stateless layer at the very front called the Router or Partition Service. Its only job is to answer one question: "Which cell owns this request?"

The routing flow looks like this:

1. Customer Alice sends a request.
2. The Router looks up Alice's tenant ID in a routing table (usually a fast in-memory cache backed by a simple key-value store).
3. The Router determines: "Alice lives in Cell 4."
4. The request is forwarded to Cell 4's load balancer.

The Router must be extremely simple and reliable. It should do no business logic, hold no mutable state, and be horizontally scalable. A common implementation is a small service that reads a routing map from a distributed cache (like Redis or DynamoDB) and proxies requests. The routing map itself changes infrequently — only when new cells are provisioned or tenants are migrated — so it can be aggressively cached.

The Router is the one component that, if it fails, affects all users. This is why it must be kept as simple as possible. Every line of code in the Router is a liability. The goal is a "dumb pipe" that does one thing perfectly.