Four service collaboration patterns: implementing distributed operations
microservice architecture service collaboration patternNew public workshop: Architecting for fast, sustainable flow - enabling DevOps and Team Topologies thru architecture. Learn more and enroll.
The microservice architecture groups an application’s subdomain into two or more services. As a result, some system operations (e.g user requests) will be distributed across multiple services.
A distributed operation spans two distinct boundaries:
- transaction boundaries - ACID transactions are local to a service and so the operation consists of multiple eventually consistent transactions. Ensuring ACID-like properties is often a key design consideration.
- process boundaries - service instances are typically processes and so inter-service communication is potentially expensive. Another design consideration is, therefore, ensuring that the operation is efficient.
A distributed operation must be implemented using one or more of the service collaboration patterns.
The service collaboration patterns
There are two patterns for implementing commands:
There are two patterns for implementing queries:
Design operations using dark energy and dark matter
The dark energy and dark matter forces patterns that shape an architecture drive the selection and application of the service collaboration patterns. Consider, for example, a query that spans multiple services. While the API composition pattern is simpler yet it might not be as performant or available as the CQRS pattern. In other words, #itDepends.
You need to use a design process, such as Assemblage, that carefully considers the dark energy/matter tradeoffs between the patterns for each system operation.
Need help migrating to microservices?
I’m available to help your organization adopt microservices. I provide consulting and workshops.
Premium content and office hours is now available for paid subscribers at 
