"Why is the cart empty?"
In a CRUD system, when a user reports a bug ("My items disappeared!"), you look at the database and see an empty cart. You have no idea how it got empty. Was it a bug? Did they accidentally click delete? Did a session timeout trigger a cleanup job? The evidence has been overwritten.
In Event Sourcing, the event stream is a complete, ordered record of everything that happened:
1. ItemAdded { item: "Shoes", time: 10:00 }
2. ItemAdded { item: "Hat", time: 10:01 }
3. ItemRemoved { item: "Shoes", time: 10:03 }
4. CartCleared { reason: "session_timeout", time: 10:05 } ← Culprit found.
You can copy the production event stream to your local machine and replay it step-by-step in a debugger. You can reconstruct the exact state at 10:00 AM, 10:04 AM, or any other moment. Debugging transforms from guesswork into forensics.
Projections: Answering Questions You Haven't Asked Yet
One of the most underappreciated benefits of Event Sourcing is the ability to build new read models from historical data. Because you have every event ever recorded, you can write a new projection — a new way of interpreting the event stream — and run it against the full history to populate a new database.
Imagine you stored events for two years and then your product team asks: "How many users added an item to their cart but never checked out?" In a CRUD system, this data was never captured. In Event Sourcing, you write a new projector that scans the historical event stream and builds exactly the table you need.
A common senior-level interview question is: "What happens when you need to fix a bug in your event handler logic?" In CQRS/Event Sourcing, the answer is projection rebuilding: you fix the projector code, delete the stale read model, and replay the entire event history through the corrected projector. The event log is immutable and correct — only your interpretation of it was wrong. This is a key architectural advantage over CRUD, where a bug that corrupts data may be unrecoverable.
Temporal Queries and Regulatory Compliance
Financial, healthcare, and legal systems often have regulatory requirements to prove the exact state of data at a specific point in time. In a CRUD system, this requires complex audit tables bolted on as an afterthought. In Event Sourcing, it is a first-class capability: replay events up to timestamp T and you have the exact state at that moment. This makes Event Sourcing a natural fit for domains with strict auditability requirements.