Glossary
Event sourcing
Event sourcing represents state as the result of applying an ordered history of recorded events.
Time and versioning
Event sourcing treats a sequence of recorded events as the primary representation from which a current state can be derived. An event states that something happened in the modeled system, such as an approval being recorded or a classification being corrected. The current view is a projection of those events. Event sourcing is an application design pattern; an event record is not automatically independent proof that the underlying real-world occurrence happened.
Practical implementations need stable event meanings, ordering rules, and a policy for correction. An erroneous event is usually countered by a later event rather than silently edited, but a corrected projection still needs to explain the earlier state. Replaying a history under changed projection code may yield a different view, so versioning and migration deserve attention. Source evidence and event metadata should remain distinguishable even when they concern the same transaction.
For a defensible record, event sourcing can show the sequence by which a recorded state changed and help reconstruct earlier projections. It does not by itself provide valid time, source reliability, or a complete account of why a decision was justified. An append-only log is one possible storage property; event sourcing is the modeling practice of deriving state from events. Bitemporal data addresses a different distinction between worldly applicability and recorded knowledge.
Example
For Halden Therapeutics AG (fictional), 'licence recorded', then 'licence corrected' events yield successive views while preserving the earlier recorded action.
The pattern and its building blocks
In event sourcing the system's source of truth is an ordered log of events, each describing something that happened, such as supplier registered or address changed. Current state is derived by replaying the events, and can be cached as snapshots for speed. Martin Fowler's note on event sourcing states the principle that all changes to application state are stored as a sequence of events, and the Microsoft Azure Architecture Center's pattern description covers its benefits and the problems to consider, among them the need to version event schemas, to handle events that arrive out of order, and to deal with the eventual consistency of read models built from the log.
Events are facts about the past and are not changed. A mistake is corrected by appending a compensating event, not by editing an old one. This gives the pattern its audit value: the log is a complete, ordered account of how the state came to be, which also provides transaction time as a by-product. Separate read models, built from the log for particular queries, allow different views of the same history.
Where it helps and where it costs
It helps where history is part of the requirement: audit, reconstruction of past states, answering what-if questions by replaying with different rules, and debugging by replaying the sequence that led to a failure. It costs in complexity: queries over current state need read models; schema changes to events must be managed for as long as the log lives; and personal data in immutable events conflicts with erasure obligations unless the design isolates it, for example by storing personal data outside the log and referring to it by key.
Event sourcing is not required for an audit trail. Many systems get an adequate audit trail from an append-only log of changes beside conventional tables. The decision should rest on whether the log needs to be the source of truth, with state derived from it, or a record kept alongside it.
A worked example
A registry of site approvals for Halden Therapeutics AG (fictional) is held as events: site proposed, inspection recorded, approval granted, approval suspended. The current status of a site is computed by replaying its events. An auditor asks why a site was shown as approved in July. The team replays the events up to the end of July and shows an approval event of 12 June, an inspection of 3 June, and no suspension until August. A later correction states that the inspection had a wrong date. The correction is a new event, dated at its entry, referring to the earlier one. The replay as of July still shows the original belief, and the replay as of September shows the corrected one.
Checks a reviewer can run
Ask whether any event can be edited or deleted and by whom. Replay the log for a sampled entity and compare with its stored state. Ask how event schema changes are handled over years. Ask where personal data live and how erasure is performed. Ask for a replay as of a past date and confirm that it matches a report produced then.
Related terms and boundaries
Event sourcing uses an append-only log as the system's truth, supplies transaction time, and makes as-of queries natural. It contributes to an audit trail and to point-in-time reproducibility. It differs from a slowly changing dimension, which stores versions of attributes and not events.
Common misreadings
- Treating an event label as proof of the external event.
- Assuming replay under revised code recreates the original output.
- Using event order as a substitute for valid time.
Found an error on this page? See corrections for what counts as one, how to report it and the dated log.
Enquiry
Where does "Event sourcing" bear on a decision of yours?
This entry sits under time and versioning. If a decision in your organization turns on it, send the entity concerned, the sources you fuse to describe it and who may read which of them. We reply with what a first record would cover.
Or write to [email protected] in your own words.