Event Sourcing Pattern in Microservices Architectures
In this article, we are going to talk about Design Patterns of Microservices architecture which is The Event Sourcing Pattern. As you know that we learned practices and patterns and add them into our design toolbox. And we will use these pattern and practices when designing e-commerce microservice architecture.
By the end of the article, you will learn where and when to apply Event Sourcing Pattern into Microservices Architecture with designing e-commerce application system.
Step by Step Design Architectures w/ Course
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.
Event Sourcing Pattern
In previous article, we have learned the CQRS Design Pattern and the CQRS pattern is mostly using with the Event Sourcing pattern.
When using CQRS with the Event Sourcing pattern, the main idea is store events into the write database, and this will be the source-of-truth events database. After that the read database of CQRS design pattern provides materialized views of the data with denormalized tables. Of course this materialized views read database consumes events from 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 saves data into databases with the current state of the entity. For example, if the user change the email address into our application, the user email field updated with the new one. So email information override the existing field of email in the user table. By this way, we always know the latest status of the data.
With applying Event Sourcing pattern, it is changing to data save operations into database. Instead of saving latest status of data into database, Event Sourcing pattern offers to save all events into database with sequential ordered of data events. This events database called event store. Instead of updating the status of a data record, it append 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 database with following the materialized views pattern. This convert operation can handle by publish/subscribe pattern with publish event with message broker systems. Also this event list gives ability to replay events at given certain timestamp and by this way it is able to build lastest status of data.
Lets look at the image. Basically this is use case of adding item into shopping cart for our e-commerce application. So we applied this use case with CQRS and Event sourcing pattern together.
As you can see that, for shopping cart, every user actions are recorded into 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 users shopping cart can be query from materialized view database. The user can see latest shopping cart status from Materialized Read Database on the e-commerce application. And as you know the writing database is never save status of data only events actions are stored. By this way, saving only events actions into write database, we can store history of data and able to reply any point of time in order to generate status of shopping cart data.
We can use event store write databases with Azure CosmosDb, Cassandra, Event Store databases so on.
So with following the Event Sourcing Pattern, we can increased query performance and scale databases independently, but of course it has some drawbacks like increase complexity.
Design the Architecture — CQRS, Event Sourcing, Eventual Consistency, Materialized View
We are going to Design our e-commerce Architecture with applying 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 user create or update an order, I am going to use relational write database, and when user query order or order history, I am going to use no-sql read database. and make consistent them when syncing 2 databases with using message broker system with applying publish/subscribe pattern.
Now we can consider tech stack of these databases,
I am going to use SQL Server for relational writing database, and using Cassandra for no-sql read database. Of course we will use Kafka for syncing these 2 database with pub/sub Kafka topic exchanges.
So we should evolve our architecture with applying other Microservices Data Patterns in order to accommodate business adaptations faster time-to-market and handle larger requests.
Step by Step Design Architectures w/ Course
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.
