Cell-Based Architecture (CBA)

platformengineering/openchoreo softwarearchitecture

SA01.8 - Domain Driven Design
Control Plane and Data Plane
North–South vs. East–West Traffic

Core Idea

Cell-based architecture slices large microservice deployments into decentralized, business-centric cells that limit blast radius, with federated governance and teams shaped to own them.

• Context and analogies (biological cells, the “terrorist cell” concept), then the core pillars.
• Anatomy of a cell, the compass mesh for network communication, and control plane versus data plane governance.
• The people dimension via Conway’s law and two-pizza teams, real-world case studies (University of Edinburgh), and technology mapping.

Cell-Based Architecture (CBA) is a decentralized, cloud-native, and people-centric reference architecture designed to solve the structural and operational complexity of large-scale Microservice deployments.

Traditionally, as organisations scale, they run into the “Death Star” problem (coined by Uber) where thousands of microservices form an unmanageable web of untraceable dependencies, causing catastrophic cascading failures, slow delivery cycles, and a breakdown of organizational boundaries.
CBA introduces a structural unit of granularity called a Cell to group related capabilities, align software architecture with team boundaries, and implement federated governance.

1. Context & Architectural Evolution

🧬 The Biological Analogy

During the conceptualization of CBA (initiated by Asanka Abeysinghe and Paul Fremantle around 2017–2018), the authors turned to systems biology to manage enterprise complexity.

• The Membrane: Just like a biological cell, an architectural cell encapsulates its internal components behind a highly secure, protective barrier.
• The Gateway: Receptors on the cell membrane control what enters and leaves, passing chemical signals without exposing the cell’s internal organelles.
• Avoiding the “Goo”: Without cells, biological organisms would just be a “big blob of molecules lying around.” Similarly, without cell boundaries, an enterprise becomes a tangled mess of microservices.

Paul Fremantle on Complexity "When you get into Enterprise Computing, you quickly realize everything is complex. Complexity is just inherent... That's why biology is so important because it's the study of complexity—trying to deal with complexity. Biology intends you to come up with complex, powerful models that actually fit better into real-world problems."

💥 The “Terrorist Cell” Concept

In the early reviews of the architecture, Sanjiva Weerawarana famously called it the “Terrorist Cell Architecture” due to its extreme isolation properties.

• Cells are completely self-contained and highly insulated.
• If a single cell is compromised, fails, or is completely “blown away”, the remaining cells continue to operate autonomously. This provides maximum fault isolation and resilience.

2. Core Pillars of Cell-Based Architecture

CBA stands on three foundational pillars:

            ┌──────────────────────────────────────────────┐
            │         Cell-Based Architecture (CBA)        │
            └──────────────────────┬───────────────────────┘
                                   │
         ┌─────────────────────────┼─────────────────────────┐
         ▼                         ▼                         ▼
┌──────────────────┐      ┌──────────────────┐      ┌──────────────────┐
│   Application    │      │    Deployment    │      │   Organization   │
│   Architecture   │      │   Architecture   │      │    (& People)    │
│  Bounded context │      │   Independently  │      │  Two-Pizza Teams │
│  via DDD APIs &  │      │ deployable units │      │  Conway's Law    │
│  versioned specs │      │   on Kubernetes  │      │  alignment       │
└──────────────────┘      └──────────────────┘      └──────────────────┘

1. Application Architecture: Groups logical components (microservices, serverless functions, legacy runtimes, databases) into a bounded context using Domain Driven Design.
2. Deployment Architecture: Standardises packaging, deployment, and execution. The entire cell is built, versioned, deployed, and scaled as a single immutable unit of software.
3. Organizational/People Architecture: Strictly aligns architectural boundaries with team boundaries, satisfying Conway’s Law (which states that software architecture mirrors the organization’s communication structures). (SA01.3 - Layered Architecture > When to Use Layered Architecture)

3. Anatomy of a Cell

A cell is a collection of components grouped from design and implementation into deployment. It is the atomic unit of scaling and management.

graph TD
    subgraph Cell ["Cell Boundary (Membrane)"]
        GW["Edge Gateway (Logical Controller)"]
        subgraph LocalMesh ["Local Mesh (Intra-Cell Communications)"]
            C1["Component A (Microservice)"]
            C2["Component B (Service / UI)"]
            C3["Component C (Function)"]
            DB[(Private Data)]
        end
    end

    %% External Interactions
    Client([Web/Mobile App]) -->|Northbound| GW
    OtherCell[[Other Cell Gateway]] -->|Westbound| GW
    
    %% Internal flow
    GW --> C1
    GW --> C2
    C1 <-->|Local Protocol| C2
    C2 <-->|Local Protocol| C3
    C3 <--> DB

    %% Outbound flows
    C3 -->|Southbound| ExtAPI[External Third-Party API]
    C1 -->|Eastbound| OtherCell

Key Elements:

• Components: The actual business logic workloads (microservices, functions, databases, frontends, or agents). Any component inside the cell can communicate freely using any protocol (HTTP, gRPC, RPC, sockets, message brokers).
• Local Mesh: The network communication plane inside the cell. Highly performant and ungoverned from the outside.
• Edge Gateway (The Membrane): The single, secure entry point of the cell. It intercepts all incoming requests, manages routing, validates tokens, applies rate-limiting, and enforces policies.
• Global Mesh: The network plane outside the cells.
• Private Data: The cell’s internal database. It is strictly encapsulated. No external cell or component can query this database directly; they must go through the cell’s versioned Gateway API.

The Flatness Principle (No Cells in Cells)

To prevent cyclic dependencies, keep architectures flat, and avoid over-engineering, the formal specification mandates that cells cannot be nested within cells (i.e., no recursive model). If a sub-team wants to organize things internally inside a cell, they are free to do so, but at the macro enterprise level, the architecture remains a flat graph of collaborating cells.

4. Network Communication Patterns (The Compass Mesh)

To streamline traffic inside the Global Mesh, CBA categorizes communication into four directional paths:

Direction	Type	Description
Northbound	Ingress	External client channels (Web, Mobile, IoT) making ingress calls into the cell’s gateway.
Southbound	Egress	Outbound calls made from within the cell to third-party APIs or external software providers outside the enterprise boundaries.
Westbound	Ingress	Internal ingress calls coming from another cell within the enterprise into this cell’s gateway.
Eastbound	Egress	Outbound egress calls initiated from within this cell to another cell’s gateway inside the enterprise.

5. Federated Governance: Control Plane vs. Data Plane

CBA balances the speed of decentralized development with the safety of centralized compliance using a Federated Governance model.

          ┌──────────────────────────────────────────┐
          │              CONTROL PLANE               │
          │ Enforces Security, Auditing, & Policies  │
          └────────────────────┬─────────────────────┘
                               │
               ┌───────────────┴───────────────┐ (Policy Propagation)
               ▼                               ▼
┌──────────────────────────────┐┌──────────────────────────────┐
│  DATA PLANE (Prod Env)       ││  DATA PLANE (Dev/Test Env)   │
│                              ││                              │
│   ┌───────┐      ┌───────┐   ││   ┌───────┐      ┌───────┐   │
│   │Cell A │ ───> │Cell B │   ││   │Cell A │ ───> │Cell B │   │
│   └───────┘      └───────┘   ││   │(v1.1) │      └───────┘   │
│                              ││   └───────┘                  │
└──────────────────────────────┘└──────────────────────────────┘

• Control Plane: Owned by the central Enterprise Architecture/SecOps team. It defines global security standards, authentication patterns, compliance auditing, and rate-limiting policies.
• Data Plane: Where the actual cells run. Divided into environmental namespaces (e.g., Development, Testing, Staging, Production). Policies configured in the Control Plane are automatically propagated and enforced directly at the Edge Gateways inside the Data Plane, removing the bottleneck of human gateway configurations.

6. The People Dimension (Conway’s Law Realized)

CBA is a people-first architecture. One of the biggest failures in modern microservices is allocating services randomly across teams, forcing high communication overhead.

Martin Jones (University of Edinburgh) "You don't build a business, you build people, and then the people build the business. It's the ideas that people come up with, their processes, and their data that underpin everything."

The Two-Pizza Team Rules:

• High Internal Cohesion: A single, empowered, and cross-functional team owns the full lifecycle of a cell (Build, Deploy, Run, Observe, Maintain).
• Autonomous Standups: If a developer needs to change an internal API of a component inside the cell, they coordinate it easily at the daily standup because the entire cell belongs to their team.
• Versioned Contracts: If a change impacts the cell boundary, they must publish a new version of the API contract, ensuring that teams managing other cells do not break.
• Ownership Constraint:

$$\text{One Team}⟹\text{Can own }\mathbf{N}\text{ Cells}$$ $$\text{One Cell}⟹\text{Must be owned by strictly }1\text{ Team}$$

_(A cell can never be co-owned by multiple teams. If it is, the boundary was drawn incorrectly.)_

7. Real-World Implementations & Case Studies

Case Study: University of Edinburgh

• Scale: Moving 60,000+ users (students, academics, staff) from monolithic on-premise infrastructure to Kubernetes-native CBA.
• Why it matters: The university experiences major performance peaks (Start of the academic year, course timetables release, student applications, billing cycles). CBA allows individual scaling of highly active cells without scaling the whole infrastructure.
• “Golden Copies” Integration: Drawn boundaries around true sources of business data (e.g., Student Cell, Finance Cell, Estates Cell).
• The Estates Cell Migration: They migrated their Estates systems from on-premises to a new cloud provider. Because the Estates Cell implemented strict API versioning, they built and deployed the cloud-native version in parallel. Users tested against both versions concurrently. On launch day, the team flipped a switch, resulting in a 10-minute seamless cutover without impacting other active university operations.

On-Prem v1.0  ───[ Estates Cell Gateway ]───> Old On-Prem System
                                                 │ (Flipped 10 mins)
Cloud v2.0    ───[ Estates Cell Gateway ]───> New Cloud Vendor

Corporate Implementations:

• Okta: Uses cell-based architecture to run highly scalable, geographically isolated, and resilient identity infrastructure.
• Booking.com: Leverages cells to segment their booking workloads and manage high volumes of transactional traffic safely.
• DoorDash: Uses a cell-based layout combined with service meshes to isolate failures and reduce inter-availability zone data transfer costs.
• Uber (DOMA): Uber’s Domain-oriented Microservice Architecture inherits heavily from CBA, grouping microservices into “Domains” and “layers” with strict gateway interfaces.

8. Technology Mapping & Platforms

┌────────────────────────────────────────────────────────┐
│               INTERNAL DEVELOPER PLATFORM              │
│               (e.g., WSO2 Choreo / Coro)               │
├───────────────────────────┬────────────────────────────┤
│   Software Engineering    │         Operations         │
│  API-First, DDD Patterns, │ CI/CD Pipelines, K8s, Mesh │
│   Platformless Abstraction│ Zero-Trust, Observability  │
└───────────────────────────┴────────────────────────────┘

Kubernetes Native Alignment

CBA maps elegantly to Kubernetes constructs:

• Simple Mapping: A Component maps to a Pod (or Deployment),and a **Cell** maps to a dedicated `Namespace`.
• Advanced Mapping: Utilizing Custom Resource Definitions (CRDs) for cells, combined with eBPF (Cilium) or Service Meshes (Istio) to securely lock down cell boundaries.
• WSO2 Choreo/Coro: Choreo is designed as an Internal Developer Platform (IDPs) with built-in Cell-Based Architecture (CBA) concepts. Projects act as cells, components are isolated, and the system automatically provides API marketplaces, zero-trust setups, and versioning out-of-the-box.
• Celery (Historical): An early open-source code-first prototype for cell deployments on K8s. It is deprecated but serves as a great pure-concept blueprint on GitHub.

9. Architectural Considerations & Anti-Patterns

⚠️ How to Mess Up Cell-Based Architecture

Even with advanced tools, teams can degrade the benefits of CBA by falling into these traps:

1. The Megacell (Monolithic Cell): Shoving the entire enterprise logic and all components into a single massive cell. This defeats the purpose of modularity, scaling, and team-level speed.
2. The “Single-Service-Per-Cell” Explosion: Creating one cell for every single microservice. This is just a standard microservice deployment with gateway overhead, eliminating the collaboration benefits within cells.
3. Mismatched Team Boundaries: Letting developers from different teams build components inside the same cell. This reintroduces scheduling conflicts and breaks Conway’s Law.

Challenges:

• Eventual Consistency: Keeping data synced across distinct private databases requires implementing event-driven architectural patterns (e.g., Sagas, Outbox Pattern). (Eventual Consistency, The Saga Pattern)
• Distributed Complexity: Debugging and tracing transactions across multiple gateways requires robust distributed tracing tools.

10. The Future: Agentic AI and “Agent Cells”

The industry is moving toward Agentic AI and Multi-Agent Systems. CBA provides a secure, organized way to govern AI inside the enterprise.

┌────────────────────────────────────────────────────────┐
│                     AGENT CELL                         │
│  ┌───────────┐      ┌───────────┐      ┌────────────┐  │
│  │ AI Agent  │ ───> │  RAG DB   │ ───> │ LLM Client │  │
│  └─────┬─────┘      └───────────┘      └────────────┘  │
└────────┼───────────────────────────────────────────────┘
         │
         ▼ (Through Managed Cell Gateway API)
 ┌──────────────┐
 │ Corporate IP │ (Secure & Governed)
 └──────────────┘

• The Problem: Many enterprises build AI systems as unregulated sidecars or completely outside the corporate perimeter, raising severe security, privacy, and compliance issues.
• The Solution: Treat AI models, agents, and RAG databases as internal components within an Agent Cell.
• Benefits: The AI is locked inside the cell boundary. It communicates with corporate data assets securely through versioned, governed APIs exposed by other cell gateways. This gives the SecOps Control Plane full visibility and enforcement over AI behavior.

11. Cell-Based Architecture vs General Microservices Architecture

	General Microservices	Cell-Based Architecture
Core unit	Individual service	Cell (group of services)
Boundary type	Technical / functional	Business domain
Entry point	Single shared API gateway	Per-cell gateway
Inter-service calls	Any service → any service	Only via cell gateways
Team ownership	Per service (can blur)	Per cell (explicit)
Versioning	Per service independently	Per cell (multiple versions can coexist)
Governance	Inconsistent, per service	Enforced at cell gateway
Data ownership	Per service (recommended)	Per cell (enforced)
Observability	Per service	Per cell + per component
Complexity	Lower initial complexity	Higher initial structure