Architecture Pattern - Cell-Based Architecture¶

Overview¶

Cell-based architecture divides a system into isolated, self-contained units called cells, each capable of independently serving a subset of users or traffic. This pattern limits the blast radius of failures, enables independent scaling, and supports progressive deployments - making it ideal for large-scale, high-availability systems.

Pattern Description¶

Problem¶

• Large monolithic or even microservice architectures can suffer from correlated failures
• A single bad deployment or infrastructure issue affects all users
• Scaling the entire system is wasteful when only part of the load is growing
• Regional failures can take down the entire application
• Shared infrastructure creates single points of failure

Solution¶

Partition the system into independent cells where: - Each cell is a complete, self-contained copy of the application stack - Cells are isolated from each other (no shared dependencies) - A routing layer assigns users/tenants to specific cells - Failures in one cell do not propagate to others - Cells can be deployed, scaled, and updated independently

flowchart TB
  U[Users / tenants] --> CR[Cell router<br/>maps tenant to cell]
  CR --> C1
  CR --> C2
  CR --> C3
  subgraph C1[Cell 1]
    A1[App tier] --> D1[(DB)]
    Q1[Queue]
    A1 --> Q1
  end
  subgraph C2[Cell 2 - failure isolated]
    A2[App tier] --> D2[(DB)]
    Q2[Queue]
    A2 --> Q2
  end
  subgraph C3[Cell 3]
    A3[App tier] --> D3[(DB)]
    Q3[Queue]
    A3 --> Q3
  end

When to Use¶

• Large-scale SaaS platforms with millions of users
• Systems requiring fault isolation and blast radius reduction
• Multi-tenant platforms needing tenant-level isolation
• Applications with strict availability requirements (99.99%+)
• Global applications needing regional data residency

When to Avoid¶

• Small applications with few users
• Systems with heavy cross-cell data dependencies
• Applications where all users must share real-time state
• Early-stage products where operational complexity is not justified

Architecture Components¶

Cell Architecture Overview¶

                    ┌─────────────────────┐
                    │    Cell Router       │
                    │  (assigns users to   │
                    │   cells)             │
                    └──────────┬──────────┘
                               │
            ┌──────────────────┼──────────────────┐
            │                  │                  │
     ┌──────▼──────┐   ┌──────▼──────┐   ┌──────▼──────┐
     │   Cell A     │   │   Cell B     │   │   Cell C     │
     │              │   │              │   │              │
     │  ┌────────┐  │   │  ┌────────┐  │   │  ┌────────┐  │
     │  │ API GW  │  │   │  │ API GW  │  │   │  │ API GW  │  │
     │  └────┬───┘  │   │  └────┬───┘  │   │  └────┬───┘  │
     │  ┌────▼───┐  │   │  ┌────▼───┐  │   │  ┌────▼───┐  │
     │  │Services │  │   │  │Services │  │   │  │Services │  │
     │  └────┬───┘  │   │  └────┬───┘  │   │  └────┬───┘  │
     │  ┌────▼───┐  │   │  ┌────▼───┐  │   │  ┌────▼───┐  │
     │  │Database │  │   │  │Database │  │   │  │Database │  │
     │  └────────┘  │   │  └────────┘  │   │  └────────┘  │
     └─────────────┘   └─────────────┘   └─────────────┘

Core Components¶

Cell Routing Strategies¶

Assignment Methods¶

Routing Implementation¶

Cloud Implementation¶

AWS Cell-Based Architecture¶

AWS Cell Architecture:

Route 53 -> CloudFront -> Lambda@Edge (cell router)
                            |
              ┌─────────────┼─────────────┐
              │             │             │
         Cell-A ALB    Cell-B ALB    Cell-C ALB
              │             │             │
         ECS Cluster   ECS Cluster   ECS Cluster
              │             │             │
         Aurora-A      Aurora-B      Aurora-C
         Redis-A       Redis-B       Redis-C

Azure Cell-Based Architecture¶

Google Cloud Cell-Based Architecture¶

Cell Sizing and Capacity¶

Sizing Guidelines¶

Cell Lifecycle¶

Failure Isolation¶

Blast Radius Comparison¶

Failure Handling¶

Deployment Strategies¶

Progressive Cell Deployment¶

Deployment Pipeline¶

Code Commit -> Build -> Test -> Deploy to Canary Cell
                                       |
                              Monitor (30 min)
                                       |
                              ┌── Pass ──> Deploy Wave 1 (3 cells)
                              │                    |
                              │           Monitor (60 min)
                              │                    |
                              │           Deploy Wave 2 (remaining cells)
                              │
                              └── Fail ──> Rollback Canary Cell
                                           Alert On-Call

Cross-Cell Concerns¶

What Can Be Shared¶

Cross-Cell Data Access¶

When data from another cell is needed (rare): 1. Async replication via events (preferred) 2. Cross-cell API calls (with circuit breakers) 3. Shared read-only data store (for reference data) 4. Data aggregation service (for analytics)

Real-World Examples¶

Certification Exam Focus Areas¶

AWS¶

• Multi-AZ and multi-Region architectures
• Route 53 routing policies for cell assignment
• DynamoDB global tables for cross-cell reference data
• CloudFormation StackSets for cell provisioning
• AWS Organizations for cell-level account isolation

Azure¶

• Availability Zones and paired regions
• Azure Front Door for global routing
• Deployment Stamps pattern (Azure's term for cell-based)
• ARM templates / Bicep modules for cell templates
• Azure Lighthouse for multi-cell management

Google Cloud¶

• Regional vs multi-regional resource deployment
• Cloud Spanner for globally consistent cross-cell data
• Deployment Manager or Terraform for cell provisioning
• GKE multi-cluster with fleet management
• Cloud Load Balancing for global cell routing

Documentation Links¶

• AWS Cell-Based Architecture: https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/
• Azure Deployment Stamps: https://learn.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp
• Google Cloud Multi-Region: https://cloud.google.com/architecture/framework/reliability
• Cell-Based Architecture (AWS Blog): https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/

Key Takeaways¶

1. Cell-based architecture is the gold standard for blast radius reduction in large-scale systems
2. The key principle is complete isolation - each cell should have zero shared dependencies with other cells
3. Cell routing is the most critical component - it must be highly available and low latency
4. Start with a small number of cells (3-5) and grow as the system scales
5. Progressive deployment across cells provides the safest deployment model
6. The operational complexity is significant - automate cell provisioning and management
7. This pattern is most valuable for systems serving millions of users with strict availability SLAs
8. AWS internally uses this pattern extensively - understanding it demonstrates advanced architectural thinking