Event Sourcing stores events that have happened as the authoritative data, then derives the current state from that history. Each event records a business change, such as “item added to cart” or “order canceled.”
Instead of knowing only that a cart contains one book, the system can know that the customer added two and removed one. This history is used to reconstruct the cart, rather than merely being kept for reference.
Suppose a cart has this history:
Reading and applying those three events in order produces the same result: one copy of book A. This is called replay, applying recorded history to calculate state.
When the customer adds more items, the system checks the request and appends a new event. If two requests modify the cart concurrently, the append must check the stream version that was read to detect conflicting changes.
Replay reconstructs data. It must not send confirmation emails or perform payments again.
Event Sourcing fits domains where change history is an important part of the business, such as a contract's lifecycle or successive order adjustments. The benefits must justify the work of retaining and processing that history.
If the application only needs the latest state and a record for inspection, conventional storage with an audit log can be simpler.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate