Event log as source of truth: the business case
Event sourcing is not just an architecture pattern. It is a way to preserve the history of changes and give analytics an honest foundation.
Most systems store only the current state. An order was created - record exists. Order changed - record updated. Order cancelled - record deleted or flagged. The history of what happened between those points is typically lost.
When everything runs smoothly, it does not matter. But when you need to investigate an incident, reconstruct a chain of decisions, or understand why the report numbers do not match - you find that there is no answer. The data is there, but the story is not.
What an event log is
An event log is an approach where the system stores not just the current state of an object, but every action that led to it. Not "order 1234 is cancelled", but "order 1234 created at 10:00, modified by manager Johnson at 11:30, cancelled by the customer at 14:45".
The current state becomes a derivative of history, not an independent fact. That is a fundamental shift.
In engineering this approach is called event sourcing. But the management value is not in the name - it is in what the company gains when such a log exists.
What this means in practice
First - incident investigation. If the system keeps a complete event log, any disputed moment can be reconstructed down to the individual event. Who changed the price? At what point did the request status flip? Why did the system produce that decision? These questions have answers.
Second - audit without extra effort. Regulatory requirements, internal reviews, investigation of customer complaints - all of these rely on an event log that is already being kept as part of normal system operation, not assembled after the fact.
Third - analytics that can be trusted. When an event log exists, an analyst can recreate the state of the system at any point in the past. This allows honest comparison across periods, without assumptions about "what the data looked like in that quarter".
Fourth - the ability to roll back and replay. Technically, an event log allows reverting system state or replaying a chain of events with changed parameters. For financial systems and operational processes this is valuable during migrations and error corrections.
Where this is unnecessary
I do not want to give the impression that an event log is needed everywhere. For simple reference data, static records, systems without meaningful change history - it is unnecessary complexity.
An event log makes sense where history matters: transactional systems, request management, financial operations, contract changes, logistics events.
The organisational question matters more than the technical one
Even with the right architecture, an event log is only useful when there is demand for it. I have seen systems with excellent logging that nobody looked at, because there was no incident review process and no one responsible for data analytics.
A few questions worth asking:
- When did we last have a dispute about what happened in a system - and were we able to resolve it from the data?
- Who in the company investigates incidents, and what data do they rely on?
- Are there audit or compliance tasks that require a history of changes?
- How much does our current analytics depend on assumptions about past data states?
If these questions produce uncomfortable silence, that is a signal the data architecture is worth reviewing - not necessarily everywhere at once, but in the key systems.