Cell Based Architecture Designer

---
name: cell-based-architecture-designer
description: 'Design cell-based (blast-radius) partitioning for a multi-tenant SaaS — a cell is a self-contained stack subset (compute + data + cache + queue) that serves a subset of tenants end to end, so a failure, bad deploy, or noisy tenant is contained to ONE cell instead of the whole fleet: cell definition, tenant→cell mapping and placement policy, a thin cell-router, cell-by-cell deployment/canary, cross-cell/global concerns, and cell migration/rebalancing. SCALE-STAGE — most SaaS never needs it; recommend cells ONLY when blast-radius reduction is the dominant lever, otherwise say so and stop. Use when a single shared stack''s blast radius is the unacceptable risk or you need per-cell deployment isolation. Do NOT use for per-component pooled/siloed isolation of one store (saas-platform-architect), choosing the architecture STYLE (architecture-advisor, whose menu omits cells), or agent blast-radius (agent-containment-reviewer).'
---

# Cell-Based Architecture Designer

## Purpose

Partition a platform into **cells** — self-contained stack subsets, each with
its own compute, primary data, cache, queue, and workers, each serving a
subset of tenants end to end — so that a failure, a bad deploy, or a noisy
tenant is contained to the blast radius of ONE cell instead of the whole
fleet. This is a **scale-stage** pattern: most SaaS never needs it, and the
first job of this skill is to say so honestly. The deliverable, when cells are
warranted, is a cell definition, a tenant→cell mapping with a placement
policy, a thin cell-router, a cell-by-cell deployment/canary plan, an
enumeration of cross-cell/global concerns, and a cell migration/rebalancing
runbook. The load-bearing property is containment: nothing a single tenant or
a single cell does should be able to take down another cell.

## Use When

- Use when: a single shared stack's blast radius is the unacceptable risk —
  one incident, one bad migration, or one hot tenant currently degrades ALL
  tenants at once, and that shared fate is the dominant problem.
- Use when: you need per-cell deployment isolation — canary a change to one
  cell of tenants and halt before it reaches the fleet.
- Use when: a shared stack has hit a real ceiling (connection limits,
  regional isolation, per-region residency) that per-component pooling or
  siloing of a single store cannot fix.
- Do NOT use when: the need is per-COMPONENT isolation of ONE store or
  service for one tenant tier (pooled vs siloed vs bridge) — that is
  `saas-platform-architect`; whole-stack cells are a far heavier hammer.
- Do NOT use when: the question is which architecture STYLE to build
  (monolith / modular monolith / microservices / event-driven) — that is
  `architecture-advisor`, whose style menu OMITS cells; it picks the
  paradigm, this skill partitions the chosen paradigm into cells.
- Do NOT use when: the blast radius in question is an AGENT's authority or
  failure propagation across an agent network — that is
  `agent-containment-reviewer`; infra cells are not agent blast radius.
- Do NOT use when: the honest answer is "you don't need cells" — a read
  replica, per-tenant siloing of the hot store, or a regional deploy
  addresses the real risk. Recommend the cheaper lever and stop.

## Inputs to Inspect

1. Current deployment topology: single shared stack, regional, or already
   partitioned — and what is stateful vs stateless within it.
2. The incident / blast-radius history that motivates cells: which real
   failures took down all tenants at once, and would a cell have contained
   them. No such history is itself a finding.
3. Tenant size distribution: the largest tenant's share of load and data —
   whether any single tenant is too big to fit in one cell.
4. Per-component isolation already in place (`saas-platform-architect`
   output): what pooling/siloing already exists, so cells are not re-solving it.
5. Cross-tenant / global features: a global directory, cross-tenant search,
   platform admin, aggregate billing/analytics — the things that CANNOT live
   inside a single cell.
6. Data residency / regional constraints that force physical placement.

## Workflow

1. **Test the premise before designing anything.** Is blast-radius reduction
   the DOMINANT lever? If a read replica (read pressure), per-tenant siloing
   of the hot store (one noisy tenant), or a regional deploy (residency)
   addresses the actual risk, recommend that instead and STOP. Cells multiply
   operational cost by cell count; adopting them for fashion is a finding.
2. **Define the cell.** Name exactly what a cell contains — the self-contained
   stack subset (compute + primary data + cache + queue + workers) — such that
   a tenant is served entirely within one cell. Everything NOT in a cell is a
   global concern (step 6).
3. **Design tenant→cell mapping and placement.** A tenant lives in exactly one
   cell. State the placement policy for new tenants (fill / balance / by-size /
   by-region) and where the mapping is stored — a global routing table, itself
   a global concern.
4. **Design the thin cell-router.** The ONLY global data-plane component:
   resolve tenant → cell from the routing table and forward. It must stay
   thin — no business logic, no per-tenant data — or it becomes the
   shared-fate component cells were meant to eliminate.
5. **Plan cell-by-cell deployment.** Deploy, migrate, and canary one cell at a
   time; a bad change is contained to one cell's tenants. State the rollout
   order, the per-cell health gate, and the halt rule that stops the fleet
   rollout on the first failing cell.
6. **Enumerate cross-cell / global concerns.** What cannot live in a cell —
   the routing table, global identity/auth, cross-tenant features, platform
   admin, aggregate billing/analytics — and how each is served WITHOUT
   becoming a single point of shared fate (replicated, cached per cell,
   degraded-mode tolerant).
7. **Design migration / rebalancing.** Moving a tenant between cells (drain →
   copy → verify → cut over → update routing), rebalancing a hot cell, and
   splitting a cell. This reshapes production data — this skill DESIGNS the
   runbook; it does not execute it.

## Output Format

```
CELL ARCHITECTURE DESIGN — <platform>
Premise check: <is blast-radius reduction the dominant lever? evidence /
  cheaper-lever recommendation if not>
Cell definition: <what one cell contains — compute/data/cache/queue/workers>
Tenant→cell mapping: <assignment, placement policy, routing-table location>
Cell-router: <thin resolve-and-forward; explicitly no business logic / no data>
Cell-by-cell deployment: <rollout order, per-cell health gate, halt rule>
Cross-cell / global concerns: <concern → how served without shared fate>
Migration / rebalancing runbook: <move a tenant; rebalance a hot cell;
  split a cell — DESIGNED, not executed>
Open questions / risks: <each with risk-if-wrong / who answers>
```

## Validation Checklist

- [ ] The premise is tested first; if a cheaper lever suffices the design
      recommends NOT adopting cells and says why.
- [ ] A cell is fully self-contained — a tenant is served end to end within
      one cell, with no runtime dependency on another cell.
- [ ] Every tenant maps to exactly one cell; the placement policy and the
      routing-table location are stated.
- [ ] The cell-router carries no business logic and no per-tenant data — it
      cannot become the shared-fate component.
- [ ] Deployment is per-cell with a halt rule; a bad change cannot reach the
      whole fleet before a cell's health gate catches it.
- [ ] Every global/cross-cell concern is enumerated with how it avoids being
      a single point of shared fate.
- [ ] Migration/rebalancing is designed as a runbook, explicitly not executed
      here; production-data moves route through human approval.

## Gotchas

- The router quietly thickens: someone adds "just one" per-tenant lookup or a
  business rule to it, and now every cell shares fate through the router again.
- Global concerns become silent SPOFs: a "global" auth service or directory
  that every cell calls synchronously re-couples the fleet — cells contain
  failure only if the global path degrades gracefully.
- Cell count multiplies operational cost linearly: migrations, deploys,
  on-call, and observability all now run ×N. Cells trade efficiency for
  containment; if containment isn't the dominant need, it's a bad trade.
- A single tenant too big for one cell breaks the model — that tenant needs
  intra-cell sharding (`data-partitioning-sharding-strategist`), not more cells.
- Cross-cell queries (a report spanning tenants in different cells) defeat the
  purpose; keep them to named, asynchronous, aggregate paths, never the hot path.
- "We adopted cells" as a resume-driven decision with no blast-radius evidence
  is the most common failure — the premise check exists to catch it.

## Stop Conditions

- The premise fails — a cheaper lever addresses the real risk → recommend NOT
  adopting cells and stop; do not design a partition scheme nobody needs.
- Migration or rebalancing must run against production (moving a tenant's live
  data between cells, splitting a cell) → this skill DESIGNS the runbook;
  executing it against production follows `human-approval-boundary`. Do not run it.
- A tenant is too large to fit one cell → the problem is intra-cell write/size
  scale; route to `data-partitioning-sharding-strategist` before forcing a
  cell design around one giant tenant.
- The real need turns out to be per-component isolation or an architecture
  style choice → hand to `saas-platform-architect` or `architecture-advisor`
  rather than over-building whole-stack cells.

## Supporting Files

- `evals/evals.json` — behavior cases: the warranted-cells design, the
  don't-adopt-cells recommendation, the too-big-tenant edge, and the router
  staying thin.
- `evals/trigger-evals.json` — discrimination against `saas-platform-architect`
  (per-component isolation), `architecture-advisor` (style choice), and
  `agent-containment-reviewer` (agent blast radius).
- No `references/` — the cell definition and global-concern enumeration above
  are the complete procedure; detail lives in the produced artifacts.