Event Sourcing
Updated 2026-08-10
INTRODUCTION
English translation pending.
CORE DEFINITION
Event sourcing stores every state change as an immutable event in an append-only log, treating the current state as a derived projection produced by replaying those events. The pattern, described by Martin Fowler and widely used with command-query responsibility segregation, provides a complete audit trail and allows a system to reconstruct its state at any past moment. Key qualification: event schemas must be designed for long-term evolution, replay performance requires periodic snapshots, and commands must be distinguished from events, since only the latter are facts about the past.
SCAFFOLDING EFFECT
Reduce cognitive load
- Record the changes: store what happened rather than only the resulting state. - Replay to inspect: rebuild any past state to understand how the current situation arose. - Separate intent from fact: distinguish a requested command from an event that actually occurred.
Anchor fast decisions
If the log of changes is complete and immutable, the current state is only a projection, so it can be recomputed or reinterpreted at any time. This makes auditing and correction possible, because the sequence that produced an error remains visible. The costs are storage growth, replay time, and the discipline required to keep event definitions stable over years.
MINIMUM ACTION
In progress 0/1Practice this model in one real situation:
account_treeGenealogyexpand_more
menu_bookReferencesexpand_more
Source support: Explicit
- martinfowler.comhttps://martinfowler.com/eaaDev/EventSourcing.htmlverified
PRIVATE NOTES · Only visible to you
SAVED Q&A
ENTRY Q&A · Private saving available
Ask with a clear boundary
thinkingmodels answers from published entry context only.
Your question is sent to thinkingmodels. The answer uses public entry context only.
RELATED MODELS