When To Use Event Sourcing (Event Sourcing Part 1)

What is Event Sourcing

Instead of only storing the current state and mutating it, we store state as a sequence of events (or changes). A good way to visualize it is your current bank balance and past transactions. Let's say you start with $0, you deposit $100, then you spend $30. This leaves you with $70. In Event Sourcing, each transaction (i.e. deposit and spend) is an event and to get the current state we combine them all ($0 + $100 - $30 = $70).

Core Concepts

• Events represent something that happened in the past. For example, MoneyDeposited not a command like DepisotMoney, events are more scalable whereas commands are tightly coupled to the downstream component.
• You need an Event Store to store your events, for example a database.
• Downstream components can subscribe to the Events.
• You can map the data of events into different views, for example a table representing the top 10 bank transactions. In Event Sourcing terms, this is called a materialised view.
• Application code for generating events is seperate to code which subscribes to events (strong decoupling).

When To Use Event Sourcing

Problem: Reading & writing with the same system can slow performance and limit scability as the same system is handling both these jobs.
Solution: Event sourcing uses separate systems to write & read the data.

Problem: Multiple processes updating the same row of data can either lead to corrupted data or degraded performance due to data locking.
Solution: Event Sourcing appends events so there is no need to lock data.

Problem: Sometimes we want to know how we reached our current state e.g. if the price of a t-shirt was $100 but is now $40. Without Event Sourcing we would only know that it's $40 but not what it was previously or why it's now $40.
Solution: With Event Sourcing we store a series of events with metadata e.g. "Initial Price: $100", then "Reduced Price for Clearance: $40". Using a series of events allows us to understand how we reached our current state.

Problem: Regular data stores have no built-in audit trail.
Solution: Storing a series of events provides a natural audit trail.