/architecture-pattern-selector

name: architecture-pattern-selector
description: Recommend architecture patterns (monolith, microservices, serverless, modular monolith) based on scale, team size, and constraints. Use when cto-architect needs to select the right architectural approach for a new system or migration.

Architecture Pattern Selector

Provides systematic framework for selecting the right architecture pattern based on real-world constraints rather than hype or resume-driven development.

When to Use

• Designing a new system from scratch
• Evaluating whether to migrate from monolith to microservices
• Choosing between serverless vs container-based architecture
• Assessing if current architecture matches actual needs

Architecture Patterns

1. Monolith

**Best for**: Early-stage products, small teams, rapid iteration

**Characteristics**:

• Single deployable unit
• Shared database
• Simple deployment and debugging
• Fastest time to market

**Choose when**:

• Team < 10 engineers
• < 100K users
• Product-market fit not yet proven
• Need to iterate quickly on features
• Limited DevOps expertise

**Avoid when**:

• Different components need independent scaling
• Multiple teams need to deploy independently
• Parts of system have very different reliability requirements

2. Modular Monolith

**Best for**: Growing products that need structure without microservices complexity

**Characteristics**:

• Single deployable unit with clear module boundaries
• Modules communicate through defined interfaces
• Can evolve to microservices later
• Best of both worlds for mid-size teams

**Choose when**:

• Team 10-30 engineers
• 100K-1M users
• Need better code organization
• Want microservices benefits without operational overhead
• Planning future extraction to services

**Avoid when**:

• Need independent deployment per module
• Modules have fundamentally different scaling requirements
• Already have microservices expertise and infrastructure

3. Microservices

**Best for**: Large organizations with mature DevOps practices

**Characteristics**:

• Independent deployable services
• Service-specific databases
• Complex operational requirements
• High organizational overhead

**Choose when**:

• Team > 30 engineers with multiple squads
• > 1M users with varying load patterns
• Different services need different scaling strategies
• Strong DevOps/Platform team
• Clear bounded contexts

**Avoid when**:

• Team lacks Kubernetes/container orchestration experience
• No dedicated platform/DevOps team
• Bounded contexts are unclear
• Chasing microservices for resume value

4. Serverless

**Best for**: Event-driven workloads, variable traffic, cost optimization

**Characteristics**:

• Pay-per-execution pricing
• Auto-scaling to zero
• Vendor lock-in concerns
• Cold start latency

**Choose when**:

• Highly variable or spiky traffic
• Event-driven processing (webhooks, queues)
• Cost-sensitive with unpredictable load
• Simple request-response patterns
• Limited DevOps capacity

**Avoid when**:

• Consistent high-volume traffic (cost inefficient)
• Low-latency requirements (< 100ms consistently)
• Long-running processes
• Complex stateful workflows

5. Hybrid

**Best for**: Complex systems with varied requirements

**Characteristics**:

• Mix of patterns for different components
• Monolith core with serverless functions
• Microservices for specific bounded contexts

**Choose when**:

• Different parts of system have different characteristics
• Migrating incrementally from monolith
• Some components need independent scaling
• Event-driven workflows alongside synchronous APIs

---

Selection Framework

Step 1: Assess Current State

Team Size:        [ ] < 10   [ ] 10-30   [ ] 30-100   [ ] > 100
User Scale:       [ ] < 100K [ ] 100K-1M [ ] 1M-10M   [ ] > 10M
DevOps Maturity:  [ ] None   [ ] Basic   [ ] Intermediate [ ] Advanced
Deployment Freq:  [ ] Monthly [ ] Weekly [ ] Daily    [ ] Multiple/day

Step 2: Evaluate Constraints

| Constraint | Impact on Pattern Choice | |------------|-------------------------| | Time to market | Favors monolith | | Team autonomy | Favors microservices | | Cost sensitivity | Favors serverless or monolith | | Latency requirements | Disfavors serverless | | Compliance/security | May require isolation (microservices) |

Step 3: Apply Decision Matrix

See [decision-matrix.md](decision-matrix.md) for the scoring framework.

Step 4: Consider Migration Path

Every architecture should have a migration path:

• Monolith → Modular Monolith → Microservices
• Monolith → Hybrid (extract specific services)
• Serverless → Containers (when scale justifies)

---

Output Format

When recommending an architecture pattern, provide:

## Architecture Recommendation

### Recommended Pattern: [Pattern Name]
**Confidence**: High / Medium / Low

### Why This Pattern
[2-3 specific reasons based on constraints]

### Trade-offs Accepted
- [Trade-off 1 and why it's acceptable]
- [Trade-off 2 and why it's acceptable]

### Migration Path
- **Current**: [Current state]
- **Phase 1**: [Near-term architecture]
- **Phase 2**: [If/when to evolve]
- **Trigger**: [What would cause migration to next phase]

### Patterns Rejected
| Pattern | Reason Not Selected |
|---------|---------------------|
| [Pattern] | [Specific reason] |

### Implementation Considerations
- [Key consideration 1]
- [Key consideration 2]
- [Key consideration 3]

---

Anti-Patterns to Avoid

Resume-Driven Architecture

Choosing microservices because it looks good on resumes, not because the problem requires it.

**Red flag**: "We should use microservices because that's what Netflix uses." **Reality check**: You're not Netflix. What's your actual scale and team size?

Premature Distribution

Distributing a system before understanding the domain boundaries.

**Red flag**: "Let's start with microservices from day one." **Reality check**: You'll draw the wrong boundaries. Start monolith, extract when clear.

##