Microservices

Event-based inter-service communication

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:

Event-based communication

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

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:

The Command Query Responsibility Segregation (CQRS)

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:

The Event Sourcing Model

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:

The Eventual Consistency

You can see the preceding diagram and can understand the Eventual Consistency pattern.

Previous
Next
Dinesh Rajput

Dinesh Rajput is the chief editor of a website Dineshonjava, a technical blog dedicated to the Spring and Java technologies. It has a series of articles related to Java technologies. Dinesh has been a Spring enthusiast since 2008 and is a Pivotal Certified Spring Professional, an author of a book Spring 5 Design Pattern, and a blogger. He has more than 10 years of experience with different aspects of Spring and Java design and development. His core expertise lies in the latest version of Spring Framework, Spring Boot, Spring Security, creating REST APIs, Microservice Architecture, Reactive Pattern, Spring AOP, Design Patterns, Struts, Hibernate, Web Services, Spring Batch, Cassandra, MongoDB, and Web Application Design and Architecture. He is currently working as a technology manager at a leading product and web development company. He worked as a developer and tech lead at the Bennett, Coleman & Co. Ltd and was the first developer in his previous company, Paytm. Dinesh is passionate about the latest Java technologies and loves to write technical blogs related to it. He is a very active member of the Java and Spring community on different forums. When it comes to the Spring Framework and Java, Dinesh tops the list!

Share
Published by
Dinesh Rajput

Recent Posts

Strategy Design Patterns using Lambda

Strategy Design Patterns We can easily create a strategy design pattern using lambda. To implement…

2 years ago

Decorator Pattern using Lambda

Decorator Pattern A decorator pattern allows a user to add new functionality to an existing…

2 years ago

Delegating pattern using lambda

Delegating pattern In software engineering, the delegation pattern is an object-oriented design pattern that allows…

2 years ago

Spring Vs Django- Know The Difference Between The Two

Technology has emerged a lot in the last decade, and now we have artificial intelligence;…

2 years ago

TOP 20 MongoDB INTERVIEW QUESTIONS 2022

Managing a database is becoming increasingly complex now due to the vast amount of data…

2 years ago

Scheduler @Scheduled Annotation Spring Boot

Overview In this article, we will explore Spring Scheduler how we could use it by…

3 years ago