Architecture
A cell-based architecture diagram with geographic routing to independent, self-contained cells (US-East, EU-West), each with its own gateway, compute, database, cache, and message queue, plus shared services for cross-cell replication and global configuration. This template models the cell architecture pattern used by hyperscale systems to achieve blast radius isolation, where failures in one cell cannot affect users in another. Key for architects designing systems that require extreme availability and fault isolation.
Full FlowZap Code
GlobalRouter { # Global Router
n1: circle label:"User Request"
n2: rectangle label:"Geographic Routing"
n3: diamond label:"User Cell Assignment?"
n4: rectangle label:"Route to Cell A"
n5: rectangle label:"Route to Cell B"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left) [label="US-East"]
n3.handle(bottom) -> n5.handle(top) [label="EU-West"]
n4.handle(bottom) -> CellA.n6.handle(top) [label="Forward"]
n5.handle(bottom) -> CellB.n12.handle(top) [label="Forward"]
}
CellA { # Cell A (US-East)
n6: rectangle label:"Cell Gateway"
n7: rectangle label:"Compute Layer"
n8: rectangle label:"Cell Database"
n9: rectangle label:"Cell Cache"
n10: rectangle label:"Cell Message Queue"
n11: circle label:"Cell Response"
n6.handle(right) -> n7.handle(left) [label="Process"]
n7.handle(right) -> n8.handle(left) [label="Read/Write"]
n7.handle(bottom) -> n9.handle(top) [label="Cache"]
n7.handle(bottom) -> n10.handle(top) [label="Async"]
n8.handle(right) -> n11.handle(left)
}
CellB { # Cell B (EU-West)
n12: rectangle label:"Cell Gateway"
n13: rectangle label:"Compute Layer"
n14: rectangle label:"Cell Database"
n15: rectangle label:"Cell Cache"
n16: rectangle label:"Cell Message Queue"
n17: circle label:"Cell Response"
n12.handle(right) -> n13.handle(left) [label="Process"]
n13.handle(right) -> n14.handle(left) [label="Read/Write"]
n13.handle(bottom) -> n15.handle(top) [label="Cache"]
n13.handle(bottom) -> n16.handle(top) [label="Async"]
n14.handle(right) -> n17.handle(left)
}
SharedServices { # Shared Services (Cross-Cell)
n18: rectangle label:"Global Config Service"
n19: rectangle label:"Cross-Cell Replication"
n20: rectangle label:"Monitoring and Alerting"
n18.handle(right) -> n19.handle(left) [label="Sync Config"]
n19.handle(top) -> CellA.n8.handle(bottom) [label="Replicate"]
n19.handle(top) -> CellB.n14.handle(bottom) [label="Replicate"]
n19.handle(right) -> n20.handle(left) [label="Health"]
}
Why This Workflow?
Traditional multi-region deployments share databases and services across regions, meaning a failure in one component can affect all users globally. Cell-based architecture creates fully independent, self-contained cells where each cell serves a subset of users—limiting the blast radius of any failure to only the users in that cell.
How It Works
- Step 1: A global router assigns users to cells based on geographic location or account ID.
- Step 2: Each cell contains its own gateway, compute, database, cache, and message queue.
- Step 3: Cells operate independently—a failure in Cell A does not affect Cell B.
- Step 4: Shared services handle cross-cell concerns like global configuration and monitoring.
- Step 5: Cross-cell replication synchronizes data for disaster recovery.
- Step 6: New cells can be added to handle growth without affecting existing cells.
Alternatives
Multi-region active-active shares resources and has larger blast radius. Single-region with failover has longer recovery times. This template shows the cell architecture used by hyperscale systems like AWS and Azure.
Key Facts
| Template Name | Cell-Based Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A bulkhead isolation architecture diagram with separate thread pools for critical, standard, and batch workloads, each with independent connection pools, exhaustion detection, and backpressure strategies to prevent one workload from starving others. This template models the bulkhead pattern inspired by ship hull compartments, where resource isolation ensures that a failure or overload in one component cannot cascade to others. Critical for systems requiring guaranteed availability for high-priority operations.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.