The arithmetic of an append-only log as the source of truth

The question is never whether something is worth doing in the abstract. It's whether it's worth doing at your volume, with your failure rate, valuing your team's time properly. So let's do the sum.

If you only store the current state, every question about how it got there is unanswerable. Keeping the sequence of things that happened and deriving state from it costs more up front and answers questions you'll otherwise pay a consultant to guess at.

WHAT AN UPDATE THROWS AWAY

An UPDATE statement destroys evidence. It replaces a fact with a different fact and keeps no record that the first one existed. In most tables that's fine. In the four or five tables that matter, it means the answer to "why does this say what it says" is permanently unavailable.

Teams work around this with audit tables bolted on beside the real ones. That's the same idea, implemented after the fact, with two problems: the audit table is written by a trigger nobody tests, and it's never quite complete enough to reconstruct anything.

DERIVED STATE IS A CACHE

The mental shift is treating the current-state table as a cache of the log rather than the truth. You can rebuild it, which means you can fix a bug in how state was computed and replay, instead of writing a migration that patches history.

That replay ability is the real return. We've fixed a two-year-old rounding bug by correcting one function and rebuilding, on a system where the alternative would have been a manual reconciliation of several thousand records.

At several million reads a day with a two percent exception rate, settlement analysts were absorbing about nine hours of manual reconciliation a week. That's the number the build had to beat, and it's a lower bar than anyone in the room expected.

THE COSTS, HONESTLY

It's more machinery. Two representations to keep in step, a replay path that needs testing, and a schema for events that's genuinely hard to change once they're in production, because the whole point is that you can't rewrite them.

So it's not a default. It earns its place where the history is itself valuable: money, regulated decisions, anything with a dispute process. Apply it to the whole system and you'll spend your budget on ceremony.

The interesting term wasn't engineering time. It was the cost of a timezone change silently duplicated an hour of consumption landing once in the wrong quarter, which the client could size to the pound and we couldn't size at all.

WHERE IT GOES WRONG

• Events with the schema of the current UI, so the log is unreadable after the next redesign.
• A replay path that was never run in anger and doesn't work when it's finally needed.
• Event sourcing applied to all forty tables, so every trivial change is a two-day exercise.
• An audit table written by an untested trigger, which turns out to be missing exactly the field you need.

Keep the sequence for the records people argue about. Derive the rest.

WHERE THE MODEL BREAKS

Do the numbers before the meeting, not during it. A decision that survives arithmetic tends to survive the next reorg too, because the reasoning outlives the people who made it.