12 Using the API Composition pattern to implement system queries

The previous chapter described how to implement distributed system commands using the Saga pattern. This pattern, which is one of the four service collaboration patterns, is needed because classic distributed transactions are not a good fit for the microservice architecture. Distributed system queries - system operations that retrieve data from multiple services - face a similar constraint. Each service is an ACID transaction boundary and owns its data and persistence, so queries cannot rely on distributed transactions or database-level joins across services.

As a result, you must also implement distributed system queries in a microservice architecture using service collaboration patterns. The two service collaboration patterns for distributed queries are API Composition, which is covered in this chapter, and CQRS, which is discussed in the next chapter. Just like the Saga pattern, they shift complexity from the infrastructure to the application.

12.1 The challenge of querying in the microservice architecture

12.1.1 System queries typically support the UI

12.1.2 The findOrder() system query

12.1.3 Why system queries need to be transactional

12.1.4 Implementing findOrder() in a monolith is straightforward

12.1.5 Challenges implementing findOrder() in a microservice architecture

12.1.6 Overview of the service collaboration patterns for queries

12.2 Using the API composition pattern

12.2.1 Overview of the API Composition pattern

12.2.2 Implementing the findOrder() system query using the API composition pattern

12.2.3 Benefits

12.2.4 Drawbacks

12.3 API composition design issues

12.3.1 The location of the API composer

12.3.2 Designing the provider queries and composition logic

12.3.3 Resilient and performant API Composition

12.4 Summary