Employing Command Query Responsibility Segregation

With Command Query Responsibility Segregation (CQRS), the data from the various microservices is aggregated to a new read-only data store that is designed to answer specific queries. The meaning of the name is that you separate (segregate) the responsibility of updating data (commands) from the responsibility of reading data (queries). Different services are in charge of those activities. It is often implemented by watching for changes to all data stores and requires a change notification system in place. You could use polling too, but that's often undesirable. This solution shines when there are known queries that are used often.

Here is an illustration of CQRS in action. The CQRS service (responsible for queries) receives a change notification from the three microservices (responsible for updates) and aggregates them into its own data store.

When a query comes, the CQRS service responds by accessing its own aggregated view without hitting the microservices:

The pros are as follows:

• Queries don't interfere with updating the primary data store.
• The aggregator service exposes an API that is tailored to specific queries.
• It's easier to change the way data is managed behind the scenes without impacting consumers.
• Quick response time.

The cons are as follows:

• It adds complexity to the system.
• It duplicates the data.
• Partial views require explicit treatment.