# Pattern: Cell-based Architecture

Status: seed
Readiness target: RL3 production
Primary owners: Railiance platform, product repos
Genesis family: Tenant isolation

## Problem

Large multi-tenant systems need blast-radius control when a single
shared runtime or data plane would make incidents too broad.

## Context

Use this pattern when tenants can be grouped into cells, shards, or
regional service instances with independent capacity, deployment, and
failure boundaries.

## Forces

- Cells reduce blast radius and scaling contention.
- Routing and tenant placement become platform responsibilities.
- Identity, policy, and audit must work across cells.
- Cross-cell operations need strict control and observability.

## Solution

Assign tenants to isolated cells that contain runtime, data, or service
subsystems. Keep global control-plane operations minimal and require
tenant-to-cell mapping in deployment, routing, policy, and audit.

## Verification

- Tenant-to-cell placement is explicit and auditable.
- Failure in one cell does not grant access to another cell.
- Deployments can be rolled out cell by cell.
- Cross-cell administrative actions are explicitly authorized.

## Related Patterns

- Tenant Isolation.
- Tenant Context Propagation.
- Central Audit Ledger.
- Kill Switch / Tenant Freeze.