paint-brush
Event Sourcing: It's Easy If You Do It Smartby@hosest
331 reads
331 reads

Event Sourcing: It's Easy If You Do It Smart

by Hossam FaresNovember 17th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Event Sourcing is amazing when only you want to track the state changes of an application, and in order to do that, you have to do some extra work. Having event sourcing is more complex to manage and store compared to not using it. Only use it when you really need it, such as when you have CQRS and event sourcing. When you have state transitions and you need to track those transitions like order operations and shipment tracking systems, like financial events and workflows, it is not necessary to couple them. In order to keep your stack simple, ask your self twice and trice before adopting it.

Company Mentioned

Mention Thumbnail
featured image - Event Sourcing: It's Easy If You Do It Smart
Hossam Fares HackerNoon profile picture

When and why you should not use event sourcing

TL;DR; Event sourcing is amazing when only you want to track the state changes of an application, and in order to do that, you have to do some extra work, try to keep your stack simple, ask your self twice and trice before adopting it.

As Martin define how its working:
The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.

Click here for his full article explaining what is event sourcing, the scope of this article is not intended for explaining that.

So shall we avoid using event sourcing at all?

Having event sourcing is more complex to manage and store compared to not using it, instead of simply overriding your application values if changes, you have to:

  1. Identify your application changes.
  2. Create events matching those changes.
  3. Store those events in order.
  4. Every time you need your application values, you need to retrieve the series of events in order and you need to reconstitutes your application as 'aggregation'.

So, I would say only use it when you really need it

Shall I always have event sourcing whenever I have CQRS?

It depends on the case you are trying to solve, even CQRS and event sourcing are playing well together and you will see a lot of frameworks provide both CQRS and eventsourcing together but it is not necessary to couple them.

Examples when you can consider having event sourcing:

  • State machine models, when you have state transitions and you need to track those transitions like order operations and shipment tracking systems.
  • Event based systems, like financial events and workflows.
  • Activity tracking systems, like tracking users in websites

Examples when you should avoid event sourcing:

  • Shopping cart changes.
  • Draft and quotation changes.
  • Product and services, unless there is you would like to track like price drops
  • Form data.

In the end, I have seen a lot of misusage of event sourcing, the misusage cost tech teams time and frustration try to take mindful decicion before adopting event sourcing