How To Understand Event Sourcing In Microservices Architecture

In a previous post, How To Understand CQRS In Microservices Architecture, a CQRS ( Command Query Responsibility Segregation) pattern was reviewed. As it was said, the CQRS pattern can be used in complex systems to separate read and write operations. In this article, the idea will be extended to an even more complex Event Sourcing pattern.

Problem Statement

The limitation of the CQRS pattern is in the fact that only the latest state of the domain entity is saved. For some applications, it is more than enough. However, more flexibility is required for other systems. It can be achieved with Event Sourcing.

Event Sourcing

Event Sourcing can be described as a set of next principles.

• Event Sourcing is usually combined with CQRS.
• All update operations of an entity are presented as a commands. Usually these commands relate to the domain area and have some meaning to the business.
• Each command is saved into append-only event log. As a result, commands are immutable and cannot change. This brings audit features out of the box.
• A service is subscribed to the event log in order to process events and provide some business value.

Event Sourcing Example

Let’s review an example.

It is a CQRS pattern (details can be found at How To Understand CQRS In Microservices Architecture).

Imagine that we are only interested in movie rating functionality. A user leaves his opinion about the movie in a form of a rating (e.g. from 0 to 10). As a result:

• User initiates Add Rating command on the Movie Actions Service.
• Movie Actions Service finds specified movie. It can contain a lot of fields. However, we are only interested in fields to calculate a rating: total number of movie votes and a sum of all movie votes.
• Information about a rating is updated. One is added to the total number of movie votes. New rating from Add Rating command is added to the sum of all movie votes.
• The full movie snapshot is sent into the Message Broker.
• All users can see an updated movie rating (the sum of all movie votes is divided by the total number of movie votes) using Movie Summary Service.

The problem with this design is in the fact that only the latest rating state is saved. The whole history is gone.

Let’s review an Event Sourcing pattern.

It is almost the same as the previous diagram. A CQRS pattern is also used here.

• User initiates Add Rating command on the Movie Actions Service.
• Event has next information: Add Rating 8 to movie The Lord of The Rings.
• Movie Actions Service saves this event into the event log (e.g. Kafka).
• Movie Summary Service has previously used total number of movie votes and fields for each movie in it’s database.
• Movie Summary Service processes records from event log and updates the rating.
• All users can see an updated movie rating (the sum of all movie votes is divided by ).

At first glance, nothing changed. However, it brought much more flexibility to the system.

The problem with movie ratings lies in the fact that people have different tastes. The general rating value (e.g. 7.35) shows only an average mark that was calculated based on the opinions of multiple people. As a company that provides movie streaming features, we are interested in providing good recommendations to our users. How we can achieve this? In order to simplify the logic, we can do it with a single statement. Recommend those movies that have similar genres to the movies that were highly rated by this user.

As a result, a new service Movie Recommendation Service is introduced.

We are extending an existing system. Consequently, Movie Recommendation Service should process all previously assigned ratings. With Event Sourcing, it is possible because we keep this information in Kafka ( Add Rating 8 to movie The Lord of The Rings). In the first example, it was not possible due to the fact that we only stored the last movie rating value.

Event Sourcing Advantages

• Separation of concerns.
• Scaling is independent for each service.
• Suitable data storage and its schema can be selected for each service.
• Simple and efficient queries in all services.
• New services can be eaasily added to an existing application.

Event Sourcing Disadvantages

• Complexity.
• Eventual consistency.
• New service can take significant amout of time to process existing events.

Summary

In this post, the Event Sourcing pattern was reviewed. It s usually used alongside CQRS. It is worth mentioning, that the necessity in this pattern can occur in complex systems. As a result, it should be chosen carefully in order not to bring unnecessary complexity to your system.

Originally published at https://datamify.com on November 25, 2021.