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..."