Cell-Based Architecture

The Cell Model

 partition users into independent FULL STACKS:

                 [router: user → cell]
                    │
      ┌─────────────┼─────────────┐
  [CELL A]      [CELL B]      [CELL C]
  api+db+cache  api+db+cache  api+db+cache
  users 0-1M    users 1-2M    users 2-3M

 each cell: its own databases, caches, queues —
 NO shared runtime between cells.
 router assigns users to cells (hash/region).

 CELL B's database melts? only its 1M users suffer.
 A and C never notice. blast radius = one cell. ✓

What Cells Buy

 □ FAILURE ISOLATION: the headline. per-cell blast radius;
   cascades cannot cross cell boundaries (no shared runtime!)
 □ LINEAR SCALING: need more capacity? add a cell. no
   re-sharding existing state, no global rebalancing drama
 □ ROLLOUT SAFETY: deploy to ONE cell first (natural canary
   at infrastructure granularity); promote cell by cell
 □ EXPERIMENTATION UNITS: whole-cell A/B tests with clean
   isolation (no cross-contamination via shared services)
 □ COMPLIANCE ZONING: EU-users cell in EU region; data
   residency by construction

The Price of Isolation

 honest costs:

 - RESOURCE OVERHEAD: N cells = N× minimum footprints
   (each needs its own headroom for failover)
   utilization drops vs one big shared pool
 - CROSS-CELL OPERATIONS get awkward:
     user moves regions → data migration between cells
     global features (search-all-users) need fan-out/aggregation
 - ROUTER becomes critical (keep it boring and replicated!)
 - OPERATIONAL SURFACE: N× everything to monitor/deploy —
   automation is MANDATORY before cell count grows

 cells trade efficiency for survivability. worth it at scale,
 overkill below it.

Cell Design Decisions

Decision	Options	Notes
Assignment	hash(user), geography, tenant-plan	stability matters; moves are costly
Cell size	capacity + failure-budget math	smaller = smaller blasts, more overhead
Shared services	identity/billing sometimes stay GLOBAL	deliberate exceptions, hardened
Cell count	start 2–3, grow by demand	automation first!

 partial-cell patterns exist: shared front tier +
 cell'd backends — common transitional shape.
 pure cells simplest to reason about when greenfield.

Who Runs Cells

 - AWS: regions/AZs are macro-cells; many services internally
   cell-based (partitioned fleets)
 - slack: cells per customer-cluster documented publicly
 - large banks/payments: regulatory + blast-radius driven
 - any system where "one bad query took everything down"
   happened more than once tends to evolve here.

 signal you're ready: incidents regularly threaten
 platform-wide impact AND scale-out pain dominates roadmaps.

Interview Framing

“500M users; design for regional failure containment” scored shape: cell diagram with router, per-cell full-stack contents, blast-radius statement (“cell death touches only its cohort”), scaling-by-adding-cells story, honest costs (utilization, cross-cell ops, mandatory automation), global-vs-shared-service boundary called out deliberately. Naming Slack/AWS as precedents grounds it — this pattern runs the biggest fleets precisely because shared-fate stops being acceptable at scale.