Event sourcing: why keeping history changes what analytics can ask
What event sourcing means as a data approach and why it is an architectural decision with long-term consequences for a company's analytical capabilities.
Most systems store current state. An order changed - the old value is overwritten. A status updated - the previous one is gone. A balance recalculated - the history of movements survives only in whatever form someone thought to plan for.
This is the familiar model. It works for operations. But it severely limits what you will be able to ask your data two years from now.
What event sourcing is
Event sourcing is an approach where a system stores not the current state of an object, but the sequence of events that led to that state. The current state is derived from the events when needed.
A practical example: instead of storing "order in status 'delivered'", the system stores "order created - paid - handed to delivery - delivered". The current status is the result of replaying that chain.
This is not a new idea. Accounting has worked this way for centuries: you do not overwrite the balance, you record every transaction, and the balance is derived from history. Banking systems are built the same way. The log model matters not just for a single system but for how systems talk to each other: an event log as the source of truth beats point-to-point integration for the same reasons.
What this gives analytically
When event history is preserved, questions become possible that simply cannot be asked when only current state is stored.
How did customer behaviour change over time? What path did an order take before it was cancelled? At what point in the process do delays occur most often? What did the product catalogue look like a year ago in the same period?
All of this requires history. If the history exists, the questions can be asked. If not, the analyst looks at current data and makes guesses about what came before.
Event sourcing also makes it possible to "rewind" state to any point in the past. This is valuable for audit, incident investigation, and debugging. Knowing where a number in a report came from - and who owns the chain of decisions that produced it - becomes answerable when the history is preserved as events.
Where it creates complexity
Event sourcing is an architectural decision with consequences, and it should not be applied everywhere.
Data volume grows faster than with current-state storage. Snapshot mechanisms are needed to avoid replaying thousands of events on every read.
Queries like "find all orders currently in status X" require a separate read layer - projections that store current state built from events.
The event schema must be stable - the past cannot be changed, only corrected by adding a new event. This requires discipline in design.
When it makes sense to think about this
Event sourcing is justified when:
- the history of changes has independent business value - for audit, analytics, or regulatory requirements;
- you need the ability to restore the state of the system at any past point in time;
- processes are complex enough that understanding how a specific result was reached matters.
For simple reference data, configuration, and anything without meaningful history - traditional state storage is simpler and sufficient.
The key question for a manager: what decisions do we make based on data, and do we need history for those decisions, or is a current snapshot enough? The answer determines whether investing in event storage is worthwhile.