Event Sourcing: The Event Log as the Source of Truth
Objectives
By the end of the lesson, you can explain how event sourcing works, what it gives, and what difficulties it brings, especially with replay and schema change.
Why is it needed?
In a traditional data store only the current state is visible: how a value got here is lost. If the history also matters — because it must be audited, replayed, or another view built from it — it is worth storing the changes instead of the state.
What is event sourcing?
According to Martin Fowler's description, event sourcing stores every change to the application state as an ordered sequence of events, and the current state can be reconstructed at any time by replaying the events. The durable event sequence is the primary source of truth; the "working copy" used for queries is derived from it.
flowchart LR
P["Command"] --> D["Rules"]
D -->|"new event"| L[("Event log")]
L -->|"replay"| S["Current state"]
L -->|"projection"| R[("Read view")]
An important distinction: in event sourcing the events describe the state (this is a way of storing), whereas the event notification of lesson 4.1 is a communication method. A system can use one without the other.
What does it give?
Fowler lists these advantages:
Audit log: the events show exactly what happened and in what order.
Rebuilding: the current state can be discarded and rebuilt from the events.
Temporal queries: by replaying events up to a point, the state at that time can be restored.
Replay to correct errors: if an event was wrong or arrived in the wrong order, the consequences can be recomputed.
Testing and debugging: real events can be replayed in a test environment.
What difficulties does it bring?
According to Fowler, the most important are:
External effects: external systems do not know whether real processing or a replay is happening; calls must go through gateways that can be switched off during replay. An old event therefore must not send an e-mail or start a payment again.
External queries: during replay, the event needs the data as it was then, not as it is now.
Code change: a bug fix may require reprocessing; time-dependent rules must be handled in the domain model.
Cost of reversal: events must store the previous value or the difference.
Schema change: events live for a long time, so changes in their format must be handled. Fowler's article does not discuss this directly; the concrete techniques are not the subject of this lesson.
Reading an event does not delete it from the event log; retention is part of the system. If the event log is used for a full rebuild, retention must be sized for that.
By aspect
Aspect
Event sourcing
Coupling
The schema of the log is the most important contract of the system
Data management
Events are the source of truth; read views are derived
Consistency
Views can lag (eventual consistency)
Failure handling
Fixable by replay, but side effects are dangerous
Cost
High: a new way of thinking, schema and retention questions
Common misconceptions
Statement
Clarification
"Event sourcing is the same as messaging."
Event sourcing is a way of storing state; messaging is a way of communicating.
"An event can be modified if it is wrong."
The event log is normally append-only; the fix is a new event or reprocessing.
"Event sourcing is always better because there is no data loss."
It has a price: schema, replay, complexity.
"Replay runs the original effects again."
Only if designed so; for external effects that would be a mistake.
In short
Event sourcing stores state changes as events; the event log is the source of truth.
Event Sourcing: The Event Log as the Source of Truth
Objectives
By the end of the lesson, you can explain how event sourcing works, what it gives, and what difficulties it brings, especially with replay and schema change.
Why is it needed?
In a traditional data store only the current state is visible: how a value got here is lost. If the history also matters — because it must be audited, replayed, or another view built from it — it is worth storing the changes instead of the state.
What is event sourcing?
According to Martin Fowler's description, event sourcing stores every change to the application state as an ordered sequence of events, and the current state can be reconstructed at any time by replaying the events. The durable event sequence is the primary source of truth; the "working copy" used for queries is derived from it.
flowchart LR P["Command"] --> D["Rules"] D -->|"new event"| L[("Event log")] L -->|"replay"| S["Current state"] L -->|"projection"| R[("Read view")]An important distinction: in event sourcing the events describe the state (this is a way of storing), whereas the event notification of lesson 4.1 is a communication method. A system can use one without the other.
What does it give?
Fowler lists these advantages:
What difficulties does it bring?
According to Fowler, the most important are:
Reading an event does not delete it from the event log; retention is part of the system. If the event log is used for a full rebuild, retention must be sized for that.
By aspect
Common misconceptions
In short
Review questions
Learning resources