belokonm 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 |