In this example, I will use Apache Kafka as a distributed message broker, offering high performance and throughput. It's one example of a messaging technology, supporting a publish/subscribe approach, among others.

At the time of writing, Apache Kafka doesn't implement all JMS semantics. The following examples will use the Kafka's vendor-specific Client API.

Apache Kafka's publish/subscribe approach organizes messages in topics. It can be configured to enable transactional event producers and in-order event consumption, which is what event-driven architectures need to ensure in order to create reliable use cases.

Kafka brokers are distributed and use so-called consumer groups to manage message topics and partitions. Examining Kafka's architecture is beyond the scope of this book and it's advised to go further into its documentation when choosing this technology.

In short, a message is published to a topic and consumed once per consumer group. Consumer groups contain one or more consumers and guarantee that exactly one consumer will process the messages that have been published using transactional producers.

A CQRS system needs to consume messages in multiple locations. The applications that are interested in a specific topic will consume the message and update their internal representations. Therefore, all these updating consumers will receive an event. There are also event handlers who use the event to process the business logic further. Exactly one event handler needs to process the event per topic, otherwise processes would run multiple times or not at all.

The concept of Kafka consumer groups is therefore used in such a way, where there is one update consumer group per application and one event handler group per topic. This enables all instances to receive the events, but reliably one command service to process the business logic. By doing so, the instances are able to scale without affecting the overall system's outcome: