Cell-Based Architecture Diagrams: Isolation Patterns for Resilient Systems (2026)

Cell-based architecture diagrams document a resilience pattern that has moved from hyperscaler internal practice to mainstream adoption in 2025–2026. A cell is a self-contained, independently deployable unit that serves a defined partition of your user population — each cell has its own copy of every service, its own database, its own cache, and its own observability stack. A failure in one cell does not cascade to others. Amazon, American Express, Slack, and Shopify have published extensively on this pattern; in 2026 it is the dominant architecture for any system where a global outage would be catastrophic. This guide explains how to diagram cell-based architectures accurately, with particular attention to the patterns emerging from agentic AI workloads that need strong tenant isolation.

What makes something a "cell"

A cell is not just a microservice cluster or a deployment environment. Architecture diagrams that call something a "cell" without meeting these properties are misleading:

• Full stack independence: Each cell contains all the services needed to handle its partition of traffic — no shared stateful services across cells. If cells share a database or cache, a failure in that shared layer affects all cells simultaneously. True cells have their own database instance, their own cache cluster, their own message queue.
• Defined population: Each cell is assigned a deterministic slice of users or tenants. The cell router (the only cross-cell component) maps a request's identifier (user ID, tenant ID, session token) to a specific cell. This mapping is stored in a routing table, not derived dynamically per-request.
• Blast radius containment: A failure in cell N affects only the users assigned to cell N — typically 1–5% of total users. Cells should be sized so that a complete cell failure stays within your SLO's acceptable degradation budget.
• Independent deployment: Cells can be deployed, scaled, and updated independently. A canary deploy goes to cell 1 first; if it fails, cells 2–N are unaffected. Rollback is a cell-level operation, not a fleet-wide one.
• No cross-cell synchronous calls: Services inside a cell never make synchronous API calls to services in another cell. Cross-cell communication, if needed at all, must be asynchronous (event bus, message queue). Synchronous cross-cell calls recreate the blast radius coupling cells are designed to prevent.

Core components in a cell-based architecture diagram

• Cell router: The only global component — routes incoming requests to the correct cell based on a routing table. The routing table maps user/tenant identifiers to cell IDs. Diagram the cell router as a thin, stateless layer backed by a replicated routing store (DynamoDB Global Tables, Redis Cluster). The router itself must be highly available; its failure affects all cells.
• Cell template: Show a single cell in detail, then show N instances of the same template. A cell diagram should include: API services, background workers, database (RDS, Postgres, DynamoDB table), cache (Redis), message queue (SQS, Kafka partition), and local observability (metrics, logs, traces forwarded to a global aggregator).
• Control plane (global): Manages cell lifecycle: provisioning new cells, updating routing table entries, draining cells for maintenance, scaling cells based on population growth. Show this as a separate management plane that communicates with cells via the cell router — not by direct API calls to cell services.
• Shuffle sharding: An advanced variant used by AWS where each customer is assigned to a unique combination (shuffle) of worker instances across cells, ensuring that even if a subset of cells fail, no two customers share the exact same set of workers. Diagram as overlapping cell membership per customer, with combinatorial routing logic in the cell router.
• Global data layer (read-only): Some data is legitimately global — feature flags, static configuration, product catalog. Show this as a separate read-only global store (DynamoDB Global Tables, S3 + CloudFront) that cells read from but never write to. Write operations go to the cell's local store only.

Cell-based patterns for agentic AI workloads (2026)

In 2026, cell-based architecture has found a new application: isolating agentic AI workloads. Multi-tenant AI platforms — where multiple customers run LLM-powered agents — need strong isolation between tenants for both security and reliability. A misbehaving agent in one tenant's cell should not exhaust GPU resources or trigger rate limits that affect other tenants:

• Agent execution cells: Each enterprise customer gets a dedicated cell for their agents: dedicated LLM inference budget (token quota per hour), dedicated vector store partition (Pinecone namespace, Weaviate tenant), dedicated tool-call sandbox (isolated Lambda execution environment), dedicated memory store (Redis namespace with TTL policies).
• GPU quota isolation: If cells share GPU inference infrastructure, use a token bucket rate limiter per cell at the inference gateway. Diagram the inference gateway as a per-cell quota enforcer — cells that exhaust their quota get queued, not allowed to consume neighbor cells' budgets.
• Tool call sandboxing: Agent tool calls (code execution, web browsing, file system access) should run in a cell-scoped sandbox with network egress restricted to the cell's approved integrations. Show the sandbox as an execution boundary within the cell — tool calls cannot reach services in other cells.
• Agent state isolation: Agent memory, conversation history, and task queues must be namespaced to the cell. Cross-cell agent memory sharing is an anti-pattern — it recreates the blast radius that cell isolation is designed to prevent.

Prompt examples for cell-based architecture diagrams

SaaS multi-tenant cell-based architecture

American Express-style cell architecture for payments

Agentic AI platform with cell isolation

Cell-based canary deployment diagram

Cell-based vs. other isolation patterns

Annotation checklist for cell-based architecture diagrams

• Cell count and sizing rationale: Annotate how many cells you have, how many users/tenants per cell, and the blast radius percentage per cell failure. This quantifies the resilience benefit and justifies the operational overhead.
• Routing table storage: Show where the cell routing table lives and its consistency model. DynamoDB Global Tables provides eventual consistency; strong-consistency reads cost 2× but prevent stale routing after cell rebalancing.
• Cross-cell data access: Explicitly label any cross-cell data access as an architectural debt item. If it exists, show whether it is synchronous (high risk) or asynchronous (lower risk) and what failure mode it introduces.
• Cell rebalancing trigger: Show the conditions that trigger adding a new cell (e.g., any cell exceeds 80% of capacity targets) and the rebalancing process — which users move, how long the dual-routing window lasts, and how data migration is handled.
• Observability aggregation: Cells emit metrics and traces independently, but you need a global view. Show the aggregation layer: per-cell Prometheus → Thanos or Grafana Mimir (global store) → dashboards that can filter by cell_id for incident scoping.

Related guides: microservices architecture diagrams, multi-tenant architecture diagrams, disaster recovery architecture, agentic AI architecture diagrams, and chaos engineering architecture.