In this article, we will discuss event-based inter-service communication in the microservice architecture. This article is part of the previous, microservice inter-service communication.
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 the 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
The Command Query Responsibility Segregation (CQRS) pattern
CQRS is an architecture design in which reading and writing are divided into different sections. This means that any given method will either be performing an action via a command or reading and processing data via a query.
In a Domain-Driven Design (DDD) application, it is recommended that you divide the application into two layers: the command side and the query side. The command side includes the write method and contains an Order Aggregate. The Order Aggregate only contains the command methods and an Order Repository, which edits the Order Aggregate. Another repository is formed for the read method and its sole task is to read and return the correct data as specified by the query entered.
CQRS can be implemented in a number of ways. One common method is to use the same database for both the read and write models. The write model edits and updates the database, whereas the read model runs the user’s query through the database, retracts the correct information or data from the database, and presents it over the user interface for the user. However, some applications can run more efficiently if two separate storage spaces are used for different methods. In this approach, the write method updates one database, which then updates the read database. The read method runs queries and retracts data from the read database.
The following diagram illustrates the CQRS pattern:
As you can see in the preceding diagram, in the CQRS pattern we split the application into two parts: the command side and the query side. On the command side, the application handles requests such as create, update, and delete, which are responsible for changing the application’s object states. On the query side, the application handles queries to fetch business data to be viewed at the frontend of the application. The CQRS pattern improves the separation of concerns by dividing the application into two separate parts.
Let’s now take a look at another event-based model pattern.
The Event Sourcing Model pattern
Event sourcing is the process of modelling your system around events. By events, we mean the current state and the changes that have occurred to that state at different stages. An object is maintained by storing a sequence of events showing the changes that have been made to the state. Every new change is appended to that sequence. Almost every application can be modelled in the event-sourcing style. A process is explained not with database tables, but as a series of events, like a story.
All events are maintained in an event store, which acts as a database. However, any user can subscribe to an event with the help of an API. When they are subscribed, the event can then be provided to the subscriber through an event store. The event store is what keeps the whole event-driven microservice architecture up and running.
In this pattern, we have to define event classes. In our example, these might be as follows:
- OrderCreated,
- OrderCanceled,
- OrderApproved,
- OrderRejected,
- OrderShipped
The following diagram shows how to create an order for a book:
As you can see in the preceding diagram, the Order Service creates an order for a book and inserts a row into the Order Table. It also publishes the event to the event store, where other services subscribe to events. For example, the Account Service subscribes to events regarding customer management and the Book Service subscribes to events regarding inventory management.
The Eventual Consistency pattern
We have already looked at an event-sourcing-based system using CQRS that has two parts: one for commands and one for queries. Having separate models raises questions about data consistency for models used at the frontend.
Eventual Consistency is a consistency model that can be applied to an event-based distributed application to achieve high availability. If no update is made to the system’s domain, it will return the last updated value for that domain. Eventual Consistency is also known as Optimistic Replication, and it is commonly used in distributed systems.
Let’s see the following diagram about the The Eventual Consistency pattern:
You can see the preceding diagram and can understand the Eventual Consistency pattern.
