The Case of the Missing $4,000

The story

A wholesale customer — Big Barrel Distributors, Pemberton & Crumb’s largest account — sent a polite but pointed email. Their store credit said $1,000. They were quite sure it should say $5,000.

Dana pulled up the account. The database agreed with itself: balance = 1000. Clean, confident, and completely unhelpful. Because the one question everyone needed answered — how did it get to $1,000? — was a question the database physically could not answer. The balance had been UPDATEd. Whatever it used to be, and whatever changed it, had been overwritten into oblivion.

Dana spent two days reconstructing the truth from log files, Stripe exports, and a support agent’s vague memory of “a refund, maybe, on Tuesday?” The answer, when it finally surfaced, was a duplicated refund script. But proving it took longer than writing the original feature.

Crumb asked the question that haunts every founder: “Can we be sure this isn’t happening to other accounts?” Dana could not.

Why this is hard the traditional way

Most systems store state: the current balance, the current status, the current address. State is efficient and easy to query — and it throws history in the bin. When you run UPDATE accounts SET balance = 1000, the fact that it was $5,000, and why it changed, is simply gone.

Teams try to patch this with an audit_log table that someone has to remember to write to, on every path, forever. It works until the day someone adds a new path and forgets — which is the exact day the auditor, or your biggest customer, comes asking. The audit log is a copy of the truth maintained by hope.

How Relay changes the ending

Event sourcing stores the events that produced the state, not just the state itself. The balance isn’t a number you overwrite — it’s the sum of everything that ever happened to the account, kept forever as an append-only sequence.

// You don't set the balance. You record what happened.
account.Apply(new FundsDeposited(amount: 5000, reason: "Quarterly top-up"));
account.Apply(new RefundIssued(amount: 4000, reason: "Order #8821 returned"));
// current balance is *derived* by replaying these — and the "why" is right there.

Now the customer’s question answers itself. Replay the account’s events and you see, in order, with timestamps and reasons, exactly how $5,000 became $1,000 — including the duplicate refund, sitting there with a guilty look. And because the log is the source of truth (not a side-table you have to remember to update), you can ask the same question of every account at once. “Is this happening elsewhere?” goes from a two-day investigation to a query.

Relay can even reconstruct what the balance was at any past moment — “show me this account as of last Tuesday” — without a time machine or a database backup.

What it costs you to ignore this

• You can’t answer “what happened?” — the single most expensive question in finance, healthcare, logistics, and anything regulated.
• Audit and compliance become archaeology. You reconstruct the past from logs and luck instead of reading it directly.
• Bugs hide. A balance that’s silently wrong looks identical to one that’s right. There’s no trail to catch the difference.
• Trust erodes. “We’re not sure why, but we’ve fixed it” is not what your biggest customer wants to hear.