Microservices Architect

Purpose

Provides expertise in designing and implementing microservices architectures. Specializes in service decomposition, inter-service communication patterns, service mesh implementation, and solving distributed systems challenges.

When to Use

Decomposing monoliths into microservices
Defining service boundaries and APIs
Implementing service mesh (Istio, Linkerd)
Designing API gateway patterns
Handling distributed transactions (Saga pattern)
Implementing event-driven communication
Setting up service discovery and load balancing
Designing for resilience (circuit breakers, retries)

Quick Start

Invoke this skill when:

Designing microservices from scratch
Decomposing existing monoliths
Implementing service-to-service communication
Setting up service mesh or API gateway
Solving distributed system challenges

Do NOT invoke when:

Migrating legacy systems incrementally → use /legacy-modernizer
Event streaming architecture → use /event-driven-architect
Kubernetes operations → use /kubernetes-specialist
Single service API design → use /api-designer

Decision Framework

Communication Pattern?
├── Synchronous
│   ├── Simple calls → REST/gRPC
│   └── Complex routing → API Gateway
├── Asynchronous
│   ├── Events → Kafka/RabbitMQ
│   └── Commands → Message queues
└── Distributed Transaction
    ├── Strong consistency → Saga (orchestration)
    └── Eventual consistency → Saga (choreography)

Core Workflows

1. Service Decomposition

Identify bounded contexts from domain model
Define service responsibilities (single purpose)
Design APIs for each service
Determine data ownership per service
Plan inter-service communication
Define deployment strategy

2. Service Mesh Implementation

Select mesh (Istio, Linkerd, Consul)
Deploy sidecar proxies
Configure traffic management
Implement mTLS for security
Set up observability (tracing, metrics)
Define retry and circuit breaker policies

3. Saga Pattern Implementation

Identify distributed transaction boundaries
Choose orchestration vs choreography
Define compensating transactions
Implement saga coordinator (if orchestrated)
Handle failure scenarios
Add monitoring for saga status

Best Practices

Design services around business capabilities, not technical layers
Own your data—each service manages its own database
Use asynchronous communication for loose coupling
Implement circuit breakers for fault tolerance
Design for failure—everything will fail eventually
Use correlation IDs for distributed tracing

Anti-Patterns

| Anti-Pattern | Problem | Correct Approach | |--------------|---------|------------------| | Distributed monolith | Coupled services, worst of both | True bounded contexts | | Shared database | Tight coupling | Database per service | | Synchronous chains | Cascading failures | Async where possible | | No circuit breakers | Cascading failures | Implement Hystrix/Resilience4j | | Nano-services | Operational overhead | Right-sized services |