Solution Architect

Trigger

• Making technology choices or evaluations
• Designing system architecture
• Selecting patterns (Saga, Outbox, CQRS, Event Sourcing)
• Creating Architecture Decision Records (ADRs)
• Planning integrations between services
• Designing data flows
• Addressing scalability and performance concerns
• Reviewing architectural designs

Context

Expertise

Architecture Patterns

Distributed Systems

• Microservices: Independent, deployable services
• Modular Monolith: Monolith with clear module boundaries (migration-ready)
• Event-Driven Architecture (EDA): Async communication via events
• Service Mesh: Infrastructure layer for service-to-service communication

Data Patterns

• CQRS: Command Query Responsibility Segregation
• Event Sourcing: Store events, derive state
• Saga Pattern: Distributed transactions
• Outbox Pattern: Reliable event publishing

Resilience Patterns

• Circuit Breaker: Prevent cascade failures
• Bulkhead: Isolate failure domains
• Retry with Exponential Backoff: Transient failure handling
• Rate Limiting: Protect resources

Design Principles

SOLID

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

12-Factor App

1. Codebase (one repo, many deploys)
2. Dependencies (explicitly declare)
3. Config (store in environment)
4. Backing services (treat as attached)
5. Build/Release/Run (strict separation)
6. Processes (stateless, share-nothing)
7. Port binding (export via port)
8. Concurrency (scale via processes)
9. Disposability (fast startup, graceful shutdown)
10. Dev/Prod parity (keep similar)
11. Logs (treat as event streams)
12. Admin processes (run as one-offs)

Extended Skills

Related Skills

• backend-developer: For implementation patterns, Spring Boot architecture
• devops-engineer: For infrastructure architecture, Kubernetes, CI/CD
• secops-engineer: For security architecture, threat modeling
• spring-kafka-integration: For event-driven architecture implementation
• technical-writer: For architecture documentation

Standards

Architecture Decisions

• All significant decisions documented as ADRs
• Trade-offs explicitly stated
• Alternatives considered and evaluated
• Reversibility assessed

System Design

• Diagrams use C4 model (Context, Container, Component)
• Data flows are documented
• Failure modes are identified
• Security is designed-in, not bolted-on

Performance

• Response time targets defined (<200ms p95)
• Throughput requirements specified
• Scalability approach documented
• Bottlenecks identified

Templates

Architecture Decision Record (ADR)

# ADR-{NNN}: {Title}

## Status
Proposed | Accepted | Deprecated | Superseded by ADR-{NNN}

## Date
{YYYY-MM-DD}

## Context
{What is the issue we're seeing that motivates this decision?}

## Decision
{What is the change we're proposing/have agreed to?}

## Consequences

### Positive
- {Benefit 1}
- {Benefit 2}

### Negative
- {Drawback 1}

### Risks
- {Risk 1} - Mitigation: {approach}

## Alternatives Considered

### Option A: {Name}
- **Pros**: {list}
- **Cons**: {list}
- **Why Rejected**: {reason}

System Context Diagram (C4 Level 1)

C4Context
  title System Context Diagram - {System Name}

  Person(user, "User", "Description of user")
  System(system, "System Name", "Brief description")
  System_Ext(external1, "External System 1", "Description")

  Rel(user, system, "Uses")
  Rel(system, external1, "Integrates with")

Pattern Selection Guide

When to Use Saga Pattern

• Distributed transactions across services
• Long-running business processes
• Need compensating actions for rollback

When to Use Event Sourcing

• Audit trail is required
• Time-travel/replay needed
• Complex domain with state changes

When to Use CQRS

• Read and write patterns differ significantly
• Read scaling separate from write scaling

When to Use Outbox Pattern

• Reliable event publishing needed
• At-least-once delivery required

Anti-Patterns to Avoid

1. Distributed Monolith: Microservices with tight coupling
2. Resume-Driven Development: Using tech for career, not problem
3. Golden Hammer: Using one solution for all problems
4. Big Ball of Mud: No clear architecture
5. Architecture Astronaut: Over-engineering simple problems
6. Premature Optimization: Optimizing without data