Architecture Pattern Selection

Systematic guidance for selecting and implementing architecture patterns that match requirements, team capabilities, and scalability needs.

When to Activate

• Designing new system architectures
• Evaluating monolith vs microservices vs serverless
• Planning scalability strategies
• Selecting technology stacks
• Creating architecture documentation
• Reviewing architecture decisions

Architecture Patterns

Monolithic Architecture

A single deployable unit containing all functionality.

┌─────────────────────────────────────────────────────────────┐
│                    Monolithic Application                    │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │  Web UI     │  │  API Layer  │  │  Admin UI   │         │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘         │
│         │                │                │                 │
│         └────────────────┼────────────────┘                 │
│                          │                                  │
│  ┌───────────────────────┴───────────────────────────┐     │
│  │              Business Logic Layer                  │     │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐        │     │
│  │  │ Orders   │  │ Users    │  │ Products │        │     │
│  │  └──────────┘  └──────────┘  └──────────┘        │     │
│  └───────────────────────┬───────────────────────────┘     │
│                          │                                  │
│  ┌───────────────────────┴───────────────────────────┐     │
│  │              Data Access Layer                     │     │
│  └───────────────────────┬───────────────────────────┘     │
│                          │                                  │
└──────────────────────────┼──────────────────────────────────┘
                           │
                    ┌──────┴──────┐
                    │  Database   │
                    └─────────────┘

When to Use:

• Small team (< 10 developers)
• Simple domain
• Rapid iteration needed
• Limited infrastructure expertise

Trade-offs:

Microservices Architecture

Independently deployable services organized around business capabilities.

┌────────┐   ┌────────┐   ┌────────┐   ┌────────┐
│ Web UI │   │Mobile  │   │ Admin  │   │External│
└───┬────┘   └───┬────┘   └───┬────┘   └───┬────┘
    │            │            │            │
    └────────────┴────────────┴────────────┘
                       │
              ┌────────┴────────┐
              │   API Gateway   │
              └────────┬────────┘
                       │
    ┌──────────────────┼──────────────────┐
    │                  │                  │
┌───┴───┐         ┌────┴───┐         ┌───┴───┐
│ Order │         │ User   │         │Product│
│Service│         │Service │         │Service│
├───────┤         ├────────┤         ├───────┤
│  DB   │         │   DB   │         │  DB   │
└───────┘         └────────┘         └───────┘
    │                  │                  │
    └──────────────────┴──────────────────┘
                       │
              ┌────────┴────────┐
              │  Message Bus    │
              └─────────────────┘

When to Use:

• Large team (> 20 developers)
• Complex, evolving domain
• Independent scaling needed
• Different tech stacks for different services
• High availability requirements

Trade-offs:

Event-Driven Architecture

Services communicate through events rather than direct calls.

┌─────────────────────────────────────────────────────────────┐
│                      Event Bus / Broker                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   OrderPlaced    UserCreated    PaymentReceived             │
│                                                             │
└──────┬──────────────┬──────────────┬───────────────────────┘
       │              │              │
       ▼              ▼              ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│   Order     │ │   User      │ │  Payment    │
│   Service   │ │   Service   │ │   Service   │
│             │ │             │ │             │
│ Publishes:  │ │ Publishes:  │ │ Publishes:  │
│ OrderPlaced │ │ UserCreated │ │ PaymentRcvd │
│             │ │             │ │             │
│ Subscribes: │ │ Subscribes: │ │ Subscribes: │
│ PaymentRcvd │ │ OrderPlaced │ │ OrderPlaced │
└─────────────┘ └─────────────┘ └─────────────┘

When to Use:

• Loose coupling required
• Asynchronous processing acceptable
• Complex workflows spanning multiple services
• Audit trail needed
• Event sourcing scenarios

Trade-offs:

Serverless Architecture

Functions executed on-demand without managing servers.

┌────────────────────────────────────────────────────────────┐
│                         Client                              │
└────────────────────────────┬───────────────────────────────┘
                             │
┌────────────────────────────┴───────────────────────────────┐
│                      API Gateway                            │
└────────────────────────────┬───────────────────────────────┘
                             │
    ┌────────────────────────┼────────────────────────┐
    │                        │                        │
    ▼                        ▼                        ▼
┌──────────┐          ┌──────────┐          ┌──────────┐
│ Function │          │ Function │          │ Function │
│ GetUser  │          │CreateOrder│         │ SendEmail│
└────┬─────┘          └────┬─────┘          └────┬─────┘
     │                     │                     │
     ▼                     ▼                     ▼
┌──────────┐          ┌──────────┐          ┌──────────┐
│ Database │          │  Queue   │          │  Email   │
│          │          │          │          │ Service  │
└──────────┘          └──────────┘          └──────────┘

When to Use:

• Variable/unpredictable workloads
• Event-triggered processing
• Cost optimization for low traffic
• Rapid development needed
• Short-running operations

Trade-offs:

Pattern Selection Guide

C4 Model

Hierarchical way to document architecture at multiple levels of detail.

Level 1: System Context

Shows system in its environment with external actors and systems.

┌──────────────────────────────────────────────────────────────┐
│                     System Context Diagram                    │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│   ┌──────────┐                           ┌──────────┐       │
│   │ Customer │                           │  Admin   │       │
│   │  [User]  │                           │  [User]  │       │
│   └────┬─────┘                           └────┬─────┘       │
│        │                                      │              │
│        │     Places orders                    │ Manages      │
│        │                                      │ products     │
│        ▼                                      ▼              │
│   ┌────────────────────────────────────────────────┐        │
│   │              E-Commerce System                  │        │
│   │                [Software System]               │        │
│   └───────────┬─────────────────┬──────────────────┘        │
│               │                 │                            │
│               │                 │                            │
│               ▼                 ▼                            │
│   ┌───────────────┐    ┌───────────────┐                    │
│   │ Payment       │    │ Email         │                    │
│   │ Gateway       │    │ Provider      │                    │
│   │ [External]    │    │ [External]    │                    │
│   └───────────────┘    └───────────────┘                    │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Level 2: Container

Shows the high-level technology choices and how containers communicate.

┌──────────────────────────────────────────────────────────────┐
│                      Container Diagram                        │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│   ┌──────────────────┐        ┌──────────────────┐          │
│   │    Web App       │        │   Mobile App     │          │
│   │  [React SPA]     │        │  [React Native]  │          │
│   └────────┬─────────┘        └────────┬─────────┘          │
│            │                           │                     │
│            │         HTTPS             │                     │
│            └───────────┬───────────────┘                     │
│                        ▼                                     │
│            ┌───────────────────────┐                         │
│            │      API Gateway      │                         │
│            │       [Kong]          │                         │
│            └───────────┬───────────┘                         │
│                        │                                     │
│       ┌────────────────┼────────────────┐                   │
│       │                │                │                    │
│       ▼                ▼                ▼                    │
│  ┌─────────┐     ┌─────────┐     ┌─────────┐               │
│  │ Order   │     │ User    │     │ Product │               │
│  │ Service │     │ Service │     │ Service │               │
│  │ [Node]  │     │ [Node]  │     │ [Go]    │               │
│  └────┬────┘     └────┬────┘     └────┬────┘               │
│       │               │               │                     │
│       ▼               ▼               ▼                     │
│  ┌─────────┐     ┌─────────┐     ┌─────────┐               │
│  │ Orders  │     │ Users   │     │Products │               │
│  │   DB    │     │   DB    │     │   DB    │               │
│  │[Postgres│     │[Postgres│     │ [Mongo] │               │
│  └─────────┘     └─────────┘     └─────────┘               │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Level 3: Component

Shows internal structure of a container.

┌──────────────────────────────────────────────────────────────┐
│                Component Diagram: Order Service               │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌───────────────────────────────────────────────────────┐  │
│  │                     API Layer                          │  │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐   │  │
│  │  │ OrdersCtrl  │  │ HealthCtrl  │  │ MetricsCtrl │   │  │
│  │  └──────┬──────┘  └─────────────┘  └─────────────┘   │  │
│  └─────────┼─────────────────────────────────────────────┘  │
│            │                                                 │
│  ┌─────────┼─────────────────────────────────────────────┐  │
│  │         ▼           Domain Layer                       │  │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐   │  │
│  │  │OrderService │  │ OrderCalc   │  │ Validators  │   │  │
│  │  └──────┬──────┘  └─────────────┘  └─────────────┘   │  │
│  └─────────┼─────────────────────────────────────────────┘  │
│            │                                                 │
│  ┌─────────┼─────────────────────────────────────────────┐  │
│  │         ▼       Infrastructure Layer                   │  │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐   │  │
│  │  │ OrderRepo   │  │PaymentClient│  │ EventPub    │   │  │
│  │  └─────────────┘  └─────────────┘  └─────────────┘   │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Level 4: Code

Shows implementation details (class diagrams, sequence diagrams).

Use standard UML when needed at this level.

Scalability Patterns

Horizontal Scaling

Add more instances of the same component.

                    Load Balancer
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         ▼               ▼               ▼
    ┌─────────┐     ┌─────────┐     ┌─────────┐
    │Instance │     │Instance │     │Instance │
    │    1    │     │    2    │     │    3    │
    └─────────┘     └─────────┘     └─────────┘

Requirements:
- Stateless services
- Shared session storage
- Database can handle connections

Caching

Reduce load on slow resources.

┌─────────────────────────────────────────────────────┐
│                  Caching Layers                      │
├─────────────────────────────────────────────────────┤
│                                                     │
│  Browser Cache → CDN → App Cache → Database Cache  │
│                                                     │
│  Examples:                                          │
│  - Browser: Static assets, API responses           │
│  - CDN: Static content, cached API responses       │
│  - App: Redis/Memcached for sessions, computed data│
│  - Database: Query cache, connection pooling       │
│                                                     │
└─────────────────────────────────────────────────────┘

Cache Invalidation Strategies:
- TTL (Time to Live): Simplest, eventual consistency
- Write-through: Update cache on write
- Write-behind: Async update for performance
- Cache-aside: App manages cache explicitly

Database Scaling

Reliability Patterns

Circuit Breaker States:

    ┌────────┐
    │ CLOSED │ ──── Failure Threshold ──► ┌────────┐
    │(normal)│                            │  OPEN  │
    └────────┘                            │(failing│
         ▲                                └────┬───┘
         │                                     │
    Success                              Timeout
    Threshold                                  │
         │                                     ▼
    ┌────┴────┐                          ┌─────────┐
    │HALF-OPEN│ ◄─── Test Request ────── │         │
    └─────────┘                          └─────────┘

Technology Selection

Selection Criteria

Evaluation Matrix

| Technology | Fit | Maturity | Skills | Perf | Ops | Cost | Score |
|------------|-----|----------|--------|------|-----|------|-------|
| Option A   | 4   | 5        | 3      | 4    | 4   | 3    | 3.8   |
| Option B   | 5   | 3        | 4      | 5    | 2   | 4    | 3.8   |
| Option C   | 3   | 4        | 5      | 3    | 5   | 5    | 4.2   |

Weights: Fit(25%), Maturity(15%), Skills(20%), Perf(15%), Ops(15%), Cost(10%)

Architecture Decision Records (ADRs)

ADR Template

# ADR-[NUMBER]: [TITLE]

## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]

## Context
[What is the issue we're facing? What decision needs to be made?]

## Decision
[What is the change we're proposing/making?]

## Consequences
### Positive
- [Benefit 1]
- [Benefit 2]

### Negative
- [Trade-off 1]
- [Trade-off 2]

### Neutral
- [Observation]

## Alternatives Considered
### Alternative 1: [Name]
- Pros: [...]
- Cons: [...]
- Why rejected: [...]

Anti-Patterns

References

• Pattern Examples – Detailed implementations
• ADR Repository – Example decision records