Agent skill · software engineering · erichowens
microservices-patterns
Microservice architecture patterns — service decomposition, inter-service communication, API gateway, saga pattern, event-driven architecture, service mesh, circuit breaker, CQRS, event sourcing.
Why this skill is useful
Provides specific patterns and strategies for microservice architecture that the AI wouldn't reliably generate on its own.
What it needs
About 10k tokens when loaded. Last updated 2026-07-14. 180 stars on the source repository.
What this skill does
Microservices Patterns The craft of decomposing systems into independent services and making them work reliably together. Covers decomposition strategies, communication patterns, data ownership, and the resilience patterns that keep a distributed system from cascading into total failure. When to Use Use for: Deciding whether to decompose a monolith and where to start Designing service boundaries using bounded contexts and domain-driven design Choosing between synchronous (REST/gRPC) and asynchronous (events) communication Implementing saga pattern for distributed transactions Designing API gateways and backend-for-frontend (BFF) layers Applying circuit breaker, bulkhead, and retry patterns Event sourcing and CQRS design Service discovery and load balancing strategies NOT for: Monolith internal architecture (use database-design-patterns, api-architect) Serverless function design and deployment Kubernetes infrastructure and deployment configuration (use terraform-iac-expert) Service mesh configuration (Istio, Linkerd) — mention it, not the core focus Single-service performance optimization (use performance-profiling) --- Core Decision: Monolith vs Microservices vs Modular Monolith When Microservices Are Worth the Cost The benefits of microservices: independent scaling, independent deployment, technology diversity, fault isolation. The cost: distributed systems complexity, eventual consistency, operational overhead, network latency. Microservices make sense when: Different parts of the system have dramatically different scaling requirements Teams are large enough that a single codebase creates coordination overhead Domains are stable enough that service boundaries will not change constantly The team has the operational maturity to manage distributed systems (observability, deployment automation, on-call) A startup with 4 engineers shipping features daily almost certainly should not be building microservices. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills erichowens/microservices-patterns