Event Sourcing From Scratch: Why Your Database Has Been Lying to You

Traditional databases lie by omission. They show you the current state of your data — but not how it got there. You see that a user's balance is $500. You don't see that they deposited $1,000, bought a $400 item, got a $200 refund, then paid a $300 subscription. The history is gone, overwritten, reduced to a single number. Event sourcing fixes this by storing every state change as an immutable event. It's the difference between a bank balance and a bank ledger. I've worked with event-sourced systems in production, and they solve problems that traditional CRUD architectures literally cannot — but they also introduce complexity you need to be honest about. The Bank Ledger Analogy Banks figured this out centuries ago. They don't store your balance by overwriting a number. They store every transaction as a separate line item: +$1,000 (deposit) -$400 (purchase) +$200 (refund) -$300 (subscription) = $500 (derived balance) Your balance is derived from replaying the history. That's event sourc