In a typical CQRS setting, there are one write data store and one or more read data stores.
As shown in the diagram below, when a user updates data via the service user interface or API, a corresponding command triggers the update of the write data store. On the other side, when a user requests to view data, one or more queries retrieve data from the read data store.
Now, how do we keep the read data stores updated or in sync with the write data store? It depends both on a particular scenario and the capabilities of the technologies used.
One option is to use a reliable messaging infrastructure with queues. In this case, we need to use a distributed transaction to ensure (1) update of the write data store and (2) sending a message to the queue to update the read data store. To support multiple read data stores, it will be a topic-subscription instead of a single queue.
However, if the write data store is an event store, it might have an in-built capability to a send message for every update on the write data store. In this case, we will not need a distributed transaction, and read date stores will be eventually consistent with the write data store.