Operational software is often pressured toward the fastest visible fix: change the current number, overwrite the current status, remove the inconvenient row. That convenience becomes expensive as soon as the business has to answer a simple question: what happened?
The durable answer is not a larger dashboard. It is a history that preserves the events capable of explaining the current view.
Summaries are views, events are evidence
Balances, inventory levels, and order states are useful summaries. They help people act. They should not be the only record of truth. A summary can be recalculated; a missing event cannot be reconstructed with confidence.
This changes implementation choices. Returns become compensating events. Adjustments retain an actor, a reason, a time, and a reference. Split payments reconcile exactly rather than approximately. The model remains understandable because each change leaves a trail.
Memory lowers the cost of change
Good history is not bureaucracy. It makes recovery, support, audit review, and product iteration less speculative. The system can evolve without pretending that its past never happened.
That is a product advantage. People trust a system more when it can explain itself.
The model is a moral choice
Every operational product decides, often quietly, whose memory matters. A mutable total is efficient when nobody asks why it changed. It is hostile the moment a customer, accountant, operator, or future teammate needs an answer. That is not only a database concern. It changes the kind of relationship a product can have with the people depending on it.
This does not mean every product needs full event sourcing. The useful question is narrower: which changes must remain explainable after the moment has passed? A team can answer it with an append-only journal, explicit adjustment records, audit tables, or carefully designed domain events. The representation is less important than the guarantee.
Memory is not event-sourcing cosplay
There is a practical trap here: copying the vocabulary of events while keeping the same mutable shortcuts. An event called inventory_changed is not useful evidence if it has no actor, reason, reference, or relation to the rule that accepted it. A history becomes valuable when a human can use it to distinguish a correction from a reversal and a late message from a new decision.
The cheapest honest model is often small. Keep the current projection for fast reads. Keep the business event that explains the projection. Keep enough metadata to replay the decision without turning the operator into a forensic archaeologist. The database is allowed to be boring; the explanation should not be missing.
The guarantee should be practical. A support person should be able to identify the event behind a balance. An operator should be able to distinguish a correction from a reversal. A product manager should be able to ask whether a new rule can be applied to old records without erasing what those records meant at the time.
A short design review
Before adding a destructive edit, ask four questions:
- Can the current value be recomputed from a durable history?
- Does the change name its actor, reason, time, and business reference?
- Is a correction represented as a new fact instead of a rewritten past?
- Can a human follow the path without reading source code?
If the answer to the last question is no, the model may be technically correct but operationally incomplete. Legibility is not decorative. It is what lets a system be repaired without guesswork.
Research notes
Martin Fowler’s Event Sourcing describes the durable idea clearly: record state changes as events so past state can be reconstructed. The point is not to copy a pattern wholesale. It is to preserve enough evidence that a product can give an honest answer when its present state is questioned.