In this tutorial, we are going to learn about Event Sourcing in Microservices.

Event Sourcing in Microservices

• Traditionally Create, Read, Update and Delete (CRUD) has issues in microservice architecture to update the records in a database.

  • CRUD is done on the online databases, reducing performance because transactions lock tables.
  • For example, if you have a database for handling orders or payments, to update a record in a database systems lock the record or entire table in order to secure the update.
  • This makes other transactions to wait, which is reducing the performance of the entire system.
  • In microservices architecture multiple services may need to update a model(i.e., an order status) in a database at the same time, then that causes concurrency problems.
  • It is not possible to know the history of events.
  • For example, if a column or field called status=1, you wouldn’t know why that status=1.

• In event sourcing, we solve this problem by doing this.

  • Microservices subscribes to Events that are relevant.
  • Restores all the captured events in a local database in the same order that the events are received.
  • By replaying all those events, you can always understand why a status=1.

Let’s have a look at this diagram in which there are some events happening in the blue background, so the events are cart created, Item 1 added, item 2 added, item 1 removed, shipping information added.

• As those events are raised, we capture and store them in a persistent event data store or event store.
• Now, if you want to query the current state of the entities there is no column as status. Instead, we have to read the event store and replay the events to rebuild that status, which is called event sourcing.