Learn-skills.dev microservices-architect

Distributed systems expert specializing in service decomposition, orchestration, and microservices architecture patterns. Use when designing microservices, defining service boundaries, implementing service mesh, or handling distributed system challenges. Triggers include "microservices", "service mesh", "service decomposition", "distributed systems", "API gateway", "event-driven".

install

source · Clone the upstream repo

git clone https://github.com/NeverSight/learn-skills.dev

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/NeverSight/learn-skills.dev "$T" && mkdir -p ~/.claude/skills && cp -r "$T/data/skills-md/404kidwiz/claude-supercode-skills/microservices-architect" ~/.claude/skills/neversight-learn-skills-dev-microservices-architect && rm -rf "$T"

manifest: data/skills-md/404kidwiz/claude-supercode-skills/microservices-architect/SKILL.md

source content

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