Design patterns and architectural approaches for building microservices and service-oriented applications, covering how services are decomposed, communicate, handle data, and stay resilient across distributed systems.
Services Patterns
Services Patterns are the recurring, named solutions practitioners reach for when decomposing an application into services — how to split a system into services, how those services communicate, how they own their data, and how they stay resilient when parts fail. Chris Richardson’s microservices.io catalog is the most widely referenced collection, but the underlying vocabulary reaches back through Service Oriented Architecture and enterprise integration.
- Decomposition patterns - Guidance for drawing service boundaries, most often by business capability or by subdomain.
- Communication patterns - Synchronous request/response, asynchronous messaging, and API composition for how services talk to one another.
- Data patterns - Database-per-service, Saga, and CQRS approaches for owning and coordinating data across services.
- Reliability patterns - Circuit breakers, retries, and bulkheads that keep a failure in one service from cascading through the estate.
I treat these patterns less as a menu to copy and more as a shared language for design reviews and governance. When a team can name why they chose database-per-service or a Saga, their Microservices architecture becomes something you can reason about, document in OpenAPI, and hand to an agent — instead of an accident nobody can explain later.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
