Cell-Based Architecture

The Idea

 CELL: a complete, self-contained slice of the stack serving
       a subset of traffic.

                    ┌─► [ cell A: LB+app+cache+db ] ── 33% users
 [ router ] ────────┼─► [ cell B: LB+app+cache+db ] ── 33% users
 (assigns cells)    └─► [ cell C: LB+app+cache+db ] ── 33% users

 each cell is a full mini-deployment. cells share nothing
 at runtime. the router maps tenants/users → cell.

Why Cells: Blast Radius Control

 unpartitioned failure modes:
 - bad deploy → 100% of users affected
 - runaway query → shared DB melts for EVERYONE
 - noisy tenant → degrades all neighbors
 - regional config bug → global incident

 with N cells:
 - same failures hit ~1/N of users
 - canary INSIDE one cell before fleet-wide rollout
 - evacuate + drain a sick cell without touching others
 
 cells turn "the service is down" into "cell C is degraded;
 we're moving its traffic." incident management changes shape.

Assignment Strategies

Strategy	Mechanism	Trade-off
By tenant	account → cell	Clean isolation; enterprise-friendly
By user hash	uid % cells	Even spread; social graphs split across cells
Geographic	region = cell	Latency win + residency compliance

 the social-graph problem: user in cell A friends user in cell B.
 answers:
 - replicate cross-cell read models (eventual consistency)
 - route-to-home-cell per ENTITY, not per user
 - accept cross-cell hops for rare interactions
 assignment dimension choice IS an architecture decision

Cell Sizing and Lifecycle

 sizing tension:
   few big cells    → simpler ops, bigger blast radius
   many small cells → tiny blast radius, more control planes to run
   practice: size so ONE cell's loss stays within SLO error budget
   (e.g., ≤1–2% of traffic), often 5–20 cells

 lifecycle machinery needed:
 - provisioning automation (cells are cattle)
 - router config updates (add/drain/evacuate)
 - rebalancing when cells fill unevenly
 - per-cell observability (metrics tagged by cell, always)

Costs, Honestly

 ✗ utilization overhead: each cell needs headroom (N × margins)
 ✗ operational multiplication: N copies of everything to monitor
 ✗ cross-cell features get harder (global search, friend graphs)
 ✗ router itself must never be the single point of failure
 
 this is why cells are for LARGE-scale or strict-isolation
 systems, not default architecture. it's the response to
 "when 0.01% of users down is still too much"

Interview Framing

Cells appear when interviewers push resilience: “region fails / bad tenant melts you — now what?” Scored mention: partition infrastructure into cells with tenant-based assignment, per-cell canaries and blast-radius math (“cell loss = 2% of users, inside budget”), plus the honest costs. Using the term accurately — cells ≠ shards of data, they’re slices of STACK — marks real familiarity.