How To Understand Event Sourcing In Microservices Architecture

Event Sourcing

• Event Sourcing?is usually combined with?CQRS.
• All update operations of an entity are presented as a command. Usually, these commands relate to the domain area and have some meaning to the business.
• Each command is saved into an 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:

• The user initiates?Add Rating?command on the?Movie Actions Service.
• Movie Actions Service?finds specified movies. 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. A 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.

• The user initiates?Add Rating?command on the?Movie Actions Service.
• The event has the next information:?Add Rating?8 to the 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?a total number of movie votes?and fields for each movie in its database.
• Movie Summary Service?processes record from?the event log?and update 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 easily added to an existing application.

Event Sourcing Disadvantages

• Complexity.
• Eventual consistency.
• New service can take a significant amount 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.