Event Sourcing Pattern
In this tutorial, we are going to talk about Design Patterns of Microservices architecture which is the Event Sourcing Pattern. We will use this pattern and practice when designing e-commerce microservice architecture.
In the previous tutorial, we have learned the CQRS Design Pattern and the CQRS pattern is mostly used with the Event Sourcing pattern.
When using CQRS with the Event Sourcing pattern, the main idea is to store events into the write database, and this will be the source-of-truth events database. After that, the read database of the CQRS design pattern provides materialized views of the data with denormalized tables. Of course, this materialized views read database consumes events from the write database and convert them into denormalized views.
Let me explain from the beginning what is the Event Sourcing Pattern. As you know that most of the applications save data into databases with the current state of the entity. For example, if the user changes the email address into our application, the user email field is updated with the new one. So email information overrides the existing field of email in the user table. In this way, we always know the latest status of the data.
By applying the Event Sourcing pattern, it is changing to data save operations into the database. Instead of saving the latest status of data into the database, the Event Sourcing pattern offers to save all events into the database with sequential order of data events. This events database is called an event store. Instead of updating the status of a data record, it appends each change to a sequential list of events.
So the Event Store becomes the source of truth for the data. After that, these event store convert to read the database by following the materialized views pattern. This covert operation can handle publish/ subscribe patterns with publish events with message broker systems. Also, this event list gives the ability to replay events at a given certain timestamp, and in this way it is able to build the latest status of data.
Let’s look at the image. Basically, this is the use case of adding items into the shopping cart for our e-commerce application. So we applied this use case with CQRS and Event sourcing pattern together.
As you can see, for the shopping cart, every user’s actions are recorded in the event store with appended events. For example, Item1 added, Item2 added, removed so on. And all these events are combined and summarized on the read database with denormalized tables into materialized view database.
So with this operation, the latest status of the user’s shopping cart can be queried from materialized view database. The user can see the latest shopping cart status from Materialized Read Database on the e-commerce application. And as you know the writing database never saves the status of data only events actions are stored. In this way, by saving only events actions into the write database, we can store the history of data and be able to reply at any point of time in order to generate the status of shopping cart data.
We can use event store write databases with Azure CosmosDb, Cassandra, Event Store databases so on.
So by following the Event Sourcing Pattern, we can increase query performance and scale databases independently, but of course, it has some drawbacks like increased complexity.
Now we are going to Design our e-commerce Architecture by applying an Event Sourcing Pattern.
Now We can Design our Ordering microservices databases. I am going to split 2 databases for Ordering microservices
1 for the write database for relational concerns
2 for the read database for querying concerns
So when the user creates or updates an order, I am going to use a relational write database, and when the user queries order or order history, I am going to use NoSQL to read the database. and make consistent them when syncing 2 databases with using message broker system with applying publish/subscribe pattern.
Now we can consider the tech stack of these databases,
I am going to use MySQL for relational writing database and using Cassandra for NoSQL read the database. Of course, we will use Kafka for syncing these 2 databases with pub/sub topic exchanges.
So we should evolve our architecture by applying other Microservices Data Patterns in order to accommodate business adaptations faster time-to-market and handle larger requests.