Following event-driven architectures, the write and read systems communicate solely via events. The events are distributed via an event store or event hub. There is no other coupling than the write systems that produce events and both write and read systems that consume for events to update their internal state.

The following snippet shows the architecture of a CQRS system:

The command and query services consume events from the event store. This is the only way for communication between them.

All services maintain a current-state representation that reflects the state of the domain entities. Entities are, for example, meal orders or cars, including the latest state of their properties. This state is kept in memory or persisted in databases.

These representations just enable the systems to contain a current state. The golden source of truth is the atomic events contained in the event store.

All application instances individually update their state representations by consuming and applying the events from the event store.

The command services contain the business logic that initiates changes to the systems. They produce events via the event store after potential command verification using their state representations.

In order to make the flow of information clear, let's go through an example meal order:

The client orders the meal at a command service instance. After a potential verification against its representation, the command service produces the OrderPlaced event to the event store. If publishing the event was successful, the orderMeal() method returns. The client can proceed with its execution.

The command service can create a meal identifier for later retrieval, for example, as a universally unique identifier:

The event store publishes the event to all consumers, which updates their internal representation accordingly. The client can access the status of the meal at the query service using its identifier. The query service will respond with its latest representation of the order.

In order to proceed with the order processing, an authority that invokes potential subsequent commands will handle the event as well:

An event handler will listen to the OrderPlaced event and invoke the prepareMeal() use case of the chef system. This subsequent command will then potentially result in new events.

The section Implementing microservices with Java EE, covers how to implement CQRS among other things.