Event-based communication is very similar to messaging. Instead of sending messages, the service instead generates events. Take a look at the following diagram:

As you can see, the Order Service generates an event. This is a signal that something has happened, such as an order for a book being generated. The services that are interested in this type of event, order generated, send a call to the Order Service.

In event-based communication, there is no need for a particular message structure from the message broker. We can also use this approach with transactional messaging to avoid Two-Phase Commit.

We have now looked at multiple approaches for inter-service communication. Deciding which one to use can be difficult because there are no hard and fast rules as to which ones are better. However, it can be useful to look at the individual situation and consider which is most suitable.

With that in mind, let’s now have a look at the following patterns, which can be used to design an event-driven architecture for a distributed application:

The Command Query Responsibility Segregation (CQRS) pattern

The Event Sourcing Modeling pattern

The Eventual Consistency pattern