What Is Event Sourcing?

What is the problem?🤨

Every pattern have born from a problem. Actually we use patterns because they are accepted solutions for specific problems and they will help us not to stuck on same problems again when we encounter. Then let’s try to understand what is the problem behind the Event Sourcing Pattern.

Let’s think about you are developing a food ordering app that customers order food from restaurants and rasturants prepare these orders in the kitchen and deliver to the customers.

How you would handle orders? You need to deliver these orders from customer to the restaruant’s kitchen and cookers will see these orders eventually and start making them. On the other hand orders may not stay same like when they first made, customers might add new food or might change ingrediants.

When we look from microservice perspective you would create a OrderService and a RestaurantService. You would create the order in the OrderService and send it to the RestaurantService in some way for example by using event queue. The best way handling changes on the orders would be using events, for example when order created OrderCreated event will be created and architecture would look like below.

Ok, now think that you are creating RestaurantService and you consume events from the OrderService via event queue and you wonder how to keep that data? In the traditional way you would directly create a table in the database and insert an record for each order, right?

But what about previous changes on the order? Because you are saving just current state of the order so you don’t know what was the previous state of the order. You can say what I would do with the previous state? Think about this, while you are doing some operation on the order some thing went wrong on the RestaurantService or another service then you need to drawback the order to the previous state. What you would do?

On the other hand you would have concurrency problem because you just updating one record and the order of multiple commands can affect the result of the record’s data.

Also you need to log the change to see what is happing. I know you can create an log table and write your logs to the table but actually there is better solution with Event Sourcing.

Ok, then let’s see the solution.

What is the solution?🤔

What if I say you don’t have to always keep one record for an order in the table? Well I know you need to have an order object to deal with it but actually you don’t need keep directly.

Think about what do you get when you consume the event queue? You get events right? Then what about you keep then directly not to keep as single object in the database. So you would have event stack not just an item so you can create your Order object by applying these events to the Order object in the constructor then you will get the Order object in the code.

In the programming perspective you need to write code like below when ever you want to get the Order object.

Isn’t this make some performance issues? Because whenever I want to get the Order object I might need to apply too much events to Order object. Of course there is solution for this. You can take snapshots of the events at sometimes then you will not apply the events before than this snapshot.

I hope this article help you to understand this consept and thank you for reading.😊