The Three-Cent Problem¶

A few years ago, a bank where we had one of our business accounts lost a transfer of 35,000 Euros. The money left one account but never arrived at the other. It happened between Christmas and New Year, so at first we assumed it was just slow. It was not slow. It was gone.

We complained. We got the money back. We changed banks. So far, so good.

But here is the thing: 35,000 Euros is noticeable. Someone checks the account, sees a missing chunk, raises the alarm. But what if it had been 3 Euros? Or 3 cents? Would anyone have noticed?

This exact scenario happened to one of our customers in the fintech sector. Not a dramatic sum disappearing, but tiny discrepancies. Three cents here. One cent there. Users doing their own math and finding numbers that did not match.

The problem: In a traditional system, you only have the current state. The balance is 1,247.03 Euros. How did it get there? You do not know. You cannot know. The history is gone, overwritten transaction by transaction. When someone says "this is wrong," all you can say is "this is what our database says."

The Five Ways Logs Lie¶

Logs feel like they should tell you what happened. But they lie:

Logs are separate from state. The balance is in the database. The calculation happened somewhere. Hope they match.
Logs are incomplete. You logged deposits and withdrawals. Did you log the intermediate rounding? Did you log the fee calculation? Did you log every step?
Logs get deleted. Retention policies. Disk space. The evidence from six months ago is gone.
Logs require interpretation. Even if you have them, you must mentally reconstruct the calculation from fragments.
Logs are afterthoughts. Nobody thought a rounding bug was worth logging. Why would they?

The Archaeology Problem¶

Traditional debugging is forensic archaeology. You dig through evidence hoping something relevant survives.

You cannot answer: "How did this balance get calculated?"

With only the current state, you can only guess. The three-cent mystery remains unsolved. You tell the customer: "We cannot reproduce the issue. The balance in our system is correct." They know it is not.

What If the History Was the System?¶

Event Sourcing inverts the model. Instead of storing the current balance and overwriting it with each transaction, you store every transaction as an immutable event:

2025-06-15 09:00  AccountOpened         { accountId: "...", type: "wealth" }
2025-06-15 09:05  DepositMade           { amount: 500.00 }
2025-07-01 00:00  ManagementFeeCharged  { percentage: 0.25 }
2025-07-15 10:30  DepositMade           { amount: 250.00 }
2025-08-01 00:00  PriceAdjusted         { factor: 1.023 }
2025-08-01 00:01  ManagementFeeCharged  { percentage: 0.25 }
...

The current balance is not stored. It is calculated by replaying these events through a projection.

This is not "better logging." This is a fundamentally different architecture.

Solving the Three-Cent Mystery¶

Back to our customer. A wealth management app where users make regular deposits, fees are charged, and prices are adjusted. The displayed account balance is calculated via a read model (projection) that sums all transaction events. Some users reported their balance was wrong. Sometimes 1 cent too little, sometimes 3 cents too much. Tiny differences, but they existed.

The difference was barely noticeable. It was not systematic: only certain accounts were affected, and not reliably reproducible. In a traditional database, only the current balance would be stored. There would be no way to trace the calculation.

With Event Sourcing, the debugging process was:

Step 1: Hypothesis¶

The team suspected the rounding logic. In the current projection, each transaction was rounded to two decimal places before being added to the running total. What if rounding at each step caused accumulated micro-errors?

Step 2: Build an alternative¶

They wrote a new projection that kept full precision during calculation and only rounded the final result.

Step 3: Replay¶

They ran all 847 events from the affected account through both projections.

Step 4: Compare¶

Old projection: 1,247.03 Euros
New projection: 1,247.06 Euros
Customer's expectation: 1,247.06 Euros

Step 5: Proof¶

The bug was found. The bug was proven. Not guessed. Not "probably this." Mathematically demonstrated by replaying the exact sequence of events.

Step 6: Fix¶

Deploy the corrected projection. Re-project all accounts. Every balance is now correct. Without changing a single event. The raw data was always right. Only the interpretation was wrong.

The Power of Immutable History¶

This story illustrates something profound. The events were always correct. Every deposit, every fee, every price adjustment was accurately recorded. The truth was preserved from the beginning.

The error was only in the interpretation. The projection logic had a bug, but because the interpretation is separate from the data, fixing the interpretation fixes everything. This separation is what makes retroactive correction possible. Not by editing history (which would be a lie), but by re-interpreting history correctly.

In a traditional database, this bug would be unfixable. The incorrect balances would be baked into the data. You could correct them going forward, but the past would remain wrong. With Event Sourcing, you correct the past by understanding it correctly.

What This Means for Your Business¶

The rounding bug took days to find because the team had to build custom tooling to trace calculations. With replay as a first-class capability, this kind of investigation becomes a standard debugging technique, dramatically reducing incident resolution time.

When they deployed the fix, they did not merely hope it worked. They proved it worked by replaying the exact events that caused the bug and comparing the results. This level of confidence is impossible when you only have the current state.

Because the events were always correct, fixing the projection fixed everything retroactively. No data migration, no manual corrections, no residual errors. And when customers asked what happened, the team could explain exactly what went wrong and demonstrate that the correction was accurate. That kind of transparency builds trust.

The Question for Your CTO¶

If you are trying to make the case for Event Sourcing in your organization, consider asking a simple question: When a customer reports a calculation discrepancy, can we trace exactly how that number was computed? If the answer is "we only have the current value," you cannot debug calculation errors. You can only guess.

The follow-up question is equally important: If we discover a bug in our business logic, can we retroactively correct all affected data? With Event Sourcing, the answer is yes, because the raw data remains correct and only the interpretation changes. With traditional systems, a bug that affects thousands of accounts over six months means painful manual reconciliation. With Event Sourcing, it means re-project and verify.

And when customers or auditors ask how you know the fix actually works, you have an answer: replay the exact events, compare before and after, show the math. That is not a claim. It is a proof.

Beyond Debugging¶

Event Sourcing does not just help when things go wrong. The same complete history that enables debugging also enables:

Auditing (see: What Aviation Teaches Us About Auditing)
Business intelligence (every transaction, every decision, preserved for analysis)
Compliance (provable calculation trails)
"What if" analysis (replay with different parameters)

The architecture that tells you what went wrong is the same architecture that tells you what went right.

Where to Go From Here¶

For related reading: What Aviation Teaches Us About Auditing explores how Event Sourcing provides audit capability by design. Don't Kill Your Users explains why semantic events (not CRUD events) make debugging possible in the first place. And Time is of the Essence discusses why timestamps matter for reconstructing what happened.

For the fundamentals, start with the Introduction to Event Sourcing. If you are ready to experiment, the Getting Started guide will have you writing events in minutes.

For questions about how Event Sourcing can improve your debugging and incident response capabilities, reach out at hello@thenativeweb.io.

Three cents. In a traditional system, this mystery would remain unsolved. With Event Sourcing, it becomes a solved equation.