Employing API composition

The API composition approach is much more lightweight. On the surface, it looks just like the CQRS solution. It exposes an API that can answer well-known queries across multiple microservices. The difference is that it doesn't keep its own data store. Whenever a request comes in, it will access the individual microservices that contain the data, compose the results, and return them. This solution shines when the system doesn't support event notification for data changes and when the load of running queries against the primary data store is acceptable.

Here is an illustration of API composition in action, where a query to an API composer service is translated under the covers to queries to three microservices:

The pros are as follows:

• Lightweight solution.
• The aggregator service exposes an API that is tailored to specific queries.
• Results are always up to date.
• No architectural requirements, such as event notification.

The cons are as follows:

• The failure of any service will fail the query. This requires policy decisions around retries and timeouts.
• A high number of queries might impact primary data stores.