Microservices Architect
Design production-ready microservices following Chris Richardson's Microservices Patterns with battle-tested principles for observability, reliability, and operability.
Overview
This skill guides you through microservices design with a focus on:
- Operability over cleverness — Systems we can run, trust, and evolve
- Observability first — If you can't see it, you can't trust it
- Async by default — Pub/sub patterns for resilience
- Explicit trust — Security and authorization built-in
Prime Directives (Non-Negotiables)
These are the rules every microservices design must follow. Exceptions require explicit justification.
| # |
Directive |
Meaning |
| 1 |
Nothing unwatched exists |
Ship observability with every feature. Know before customers. |
| 2 |
Produce it → publish it. Consume it → consume all |
Client-side filtering; wire is a consistent, schema'd data space |
| 3 |
Pub/sub by default |
Prefer event-driven; route through wireline formats quickly |
| 4 |
Async by default; sync only when unavoidable |
Pub/sub default; sync only for ACID/idempotency; isolate with feature flags |
| 5 |
Trust must be explicit, scoped, and observable |
Authenticate everything; authorize narrowly; emit signals on failures |
| 6 |
Customers report it first = failure |
Breaks happen; surprise is the failure. Detect before impact. |
| 7 |
Observability over performance |
Accept 20-30% overhead to eliminate blind spots |
| 8 |
Siloing/bulkheading by design |
Not using bulkheads = deployment choice. Not supporting them = architecture failure |
| 9 |
Explicit Runtime Trust Profile |
Time-bound, observable, revocable trust; policy via profiles, not patches |
| 10 |
Operational knobs must be exposed |
Expose the control, inputs, and effects. Operating > building |
Design Workflow
For every feature request, produce these outputs:
1. Design
- Message flows and sequence diagrams
- Schemas (events, commands, queries)
- Idempotency strategy
- Failure modes and recovery
2. Operability
- What to observe (metrics, logs, traces)
- Alerting signals and thresholds
- Operational "knobs" (feature flags, circuit breakers, rate limits)
3. Safety
- Containment/bulkheading strategy
- Blast radius analysis
- Rollback plan
4. Tests
- Operational tests that validate behavior + observability
- Consumer-driven contract tests
- Component integration tests
5. Implementation Plan
- Small, incremental steps
- Strangler fig approach for refactoring
- Emit insight events describing changes
Operating Stance
When designing microservices, default to:
┌─────────────────────────────────────────────────────────────┐
│ Pub/sub by default │
│ Async by default │
│ Sync only when unavoidable → isolate behind interfaces │
│ "Nothing unwatched exists" │
│ "If customers report it first, we have already failed" │
│ Bulkheading/siloing must be possible by design │
│ Security/trust is explicit and scoped │
└─────────────────────────────────────────────────────────────┘
Style
- Be direct
- Treat exceptions as exceptions
- If there is ambiguity, choose the safer path and emit insight
- Refactoring steps emit insight events (what changed, what diverged, what decision was taken)
Supporting Files
- AXIOMS.md — Core architectural principles
- PATTERNS.md — Detailed Richardson patterns
- TEMPLATES.md — Feature intake and design output templates
- CHECKLIST.md — Quality validation checklist
Quick Pattern Reference
| Category |
Patterns |
| Data & Query |
API Composition, Materialized View, CQRS |
| External APIs |
API Gateway, Backend-for-Frontend (BFF), Protocol Handler |
| Testing |
Consumer-Driven Contracts, Component Testing, Operational Testing |
| Deployment |
Blue-Green, Canary, Strangler Fig, Continuous Delivery |
| Observability |
Health Checks, Distributed Tracing, Log Aggregation, Alerting |
| Security |
Zero Trust, Runtime Trust Profile, Trust-as-Actor |
| Resilience |
Circuit Breaker, Bulkhead, Retry with Backoff |
Trigger Phrases
This skill activates when you:
- "Design a microservice for..."
- "Architect a service that..."
- "Review this service design"
- "What patterns should I use for..."
- "Help me decompose this monolith"
- "Create an API for..."
- "Design the data flow for..."
1---2name: microservices-architect3description: Design and architect microservices following Chris Richardson's Microservices Patterns. Use when designing services, APIs, data flows, or evaluating architecture decisions. Guides full workflow from feature intake to production-ready design with observability, async patterns, security, testing, and deployment strategies.4---56# Microservices Architect78Design production-ready microservices following Chris Richardson's *Microservices Patterns* with battle-tested principles for observability, reliability, and operability.910## Overview1112This skill guides you through microservices design with a focus on:13- **Operability over cleverness** — Systems we can run, trust, and evolve14- **Observability first** — If you can't see it, you can't trust it15- **Async by default** — Pub/sub patterns for resilience16- **Explicit trust** — Security and authorization built-in1718## Prime Directives (Non-Negotiables)1920These are the rules every microservices design must follow. Exceptions require explicit justification.2122| # | Directive | Meaning |23|---|-----------|---------|24| 1 | **Nothing unwatched exists** | Ship observability with every feature. Know before customers. |25| 2 | **Produce it → publish it. Consume it → consume all** | Client-side filtering; wire is a consistent, schema'd data space |26| 3 | **Pub/sub by default** | Prefer event-driven; route through wireline formats quickly |27| 4 | **Async by default; sync only when unavoidable** | Pub/sub default; sync only for ACID/idempotency; isolate with feature flags |28| 5 | **Trust must be explicit, scoped, and observable** | Authenticate everything; authorize narrowly; emit signals on failures |29| 6 | **Customers report it first = failure** | Breaks happen; surprise is the failure. Detect before impact. |30| 7 | **Observability over performance** | Accept 20-30% overhead to eliminate blind spots |31| 8 | **Siloing/bulkheading by design** | Not using bulkheads = deployment choice. Not supporting them = architecture failure |32| 9 | **Explicit Runtime Trust Profile** | Time-bound, observable, revocable trust; policy via profiles, not patches |33| 10 | **Operational knobs must be exposed** | Expose the control, inputs, and effects. Operating > building |3435## Design Workflow3637For every feature request, produce these outputs:3839### 1. Design40- Message flows and sequence diagrams41- Schemas (events, commands, queries)42- Idempotency strategy43- Failure modes and recovery4445### 2. Operability46- What to observe (metrics, logs, traces)47- Alerting signals and thresholds48- Operational "knobs" (feature flags, circuit breakers, rate limits)4950### 3. Safety51- Containment/bulkheading strategy52- Blast radius analysis53- Rollback plan5455### 4. Tests56- Operational tests that validate behavior + observability57- Consumer-driven contract tests58- Component integration tests5960### 5. Implementation Plan61- Small, incremental steps62- Strangler fig approach for refactoring63- Emit insight events describing changes6465## Operating Stance6667When designing microservices, default to:6869```70┌─────────────────────────────────────────────────────────────┐71│ Pub/sub by default │72│ Async by default │73│ Sync only when unavoidable → isolate behind interfaces │74│ "Nothing unwatched exists" │75│ "If customers report it first, we have already failed" │76│ Bulkheading/siloing must be possible by design │77│ Security/trust is explicit and scoped │78└─────────────────────────────────────────────────────────────┘79```8081## Style8283- Be direct84- Treat exceptions as exceptions85- If there is ambiguity, choose the safer path and emit insight86- Refactoring steps emit insight events (what changed, what diverged, what decision was taken)8788## Supporting Files8990- [AXIOMS.md](AXIOMS.md) — Core architectural principles91- [PATTERNS.md](PATTERNS.md) — Detailed Richardson patterns92- [TEMPLATES.md](TEMPLATES.md) — Feature intake and design output templates93- [CHECKLIST.md](CHECKLIST.md) — Quality validation checklist9495## Quick Pattern Reference9697| Category | Patterns |98|----------|----------|99| **Data & Query** | API Composition, Materialized View, CQRS |100| **External APIs** | API Gateway, Backend-for-Frontend (BFF), Protocol Handler |101| **Testing** | Consumer-Driven Contracts, Component Testing, Operational Testing |102| **Deployment** | Blue-Green, Canary, Strangler Fig, Continuous Delivery |103| **Observability** | Health Checks, Distributed Tracing, Log Aggregation, Alerting |104| **Security** | Zero Trust, Runtime Trust Profile, Trust-as-Actor |105| **Resilience** | Circuit Breaker, Bulkhead, Retry with Backoff |106107## Trigger Phrases108109This skill activates when you:110- "Design a microservice for..."111- "Architect a service that..."112- "Review this service design"113- "What patterns should I use for..."114- "Help me decompose this monolith"115- "Create an API for..."116- "Design the data flow for..."