What is Event Sourcing?

Where the idea comes from

The pattern has older roots than software. Double-entry accounting, invented in the 13th century, is an event-sourced system — you never erase a transaction, you write a correcting one. Martin Fowler's 2005 essay codified event sourcing for software engineers, and Greg Young's talks in the late 2000s pushed it into the mainstream of the domain-driven design community. Today it shows up in financial ledgers, trading systems, collaborative editors like Figma, version-control systems, and any product whose audit trail is a regulatory requirement.

How it differs from CRUD

A standard CRUD application has a row in a table that gets updated in place. A user changes their email and the email column is overwritten. The old email is gone unless you remembered to add an audit table. Event sourcing inverts that. The system stores an UserEmailChanged event with the old value, the new value, who did it, and when. The user's current email is whatever the most recent UserEmailChanged event says it is, computed by walking the log. The row in the application database is a projection of the log, not the source of truth.

That shift has real consequences. Bugs become recoverable — you replay the log up to the point before the bad code shipped and rebuild a clean state. Audits become trivial — you can produce a record of every change to any aggregate, ever. Integration becomes easier — other services subscribe to the event stream rather than polling the database.

Where it pairs with CQRS

Event sourcing and CQRS are often discussed together because they fit so naturally. CQRS separates the model used to write data from the model used to read it. Event sourcing gives the write model a perfect implementation — an append-only log — and lets the read side build whatever projections it needs. You can have multiple read models off the same event stream: one for the application UI, one for analytics, one for compliance reports.

The honest downsides

Event sourcing is not free. Schema evolution is the hard problem — once you have a billion events of a given type in the log, changing the event shape is something between annoying and treacherous, because the old events still have to be replayable forever. Queries against current state require a projection layer; you cannot just write a SELECT to find every active user the way you would in a CRUD app. The cognitive load on the engineering team is meaningfully higher than a normal database-backed application, and teams that adopt event sourcing without buying into domain-driven design often regret it within a year.

At QUANT LAB

We use event sourcing when the audit trail is part of the product spec, not an afterthought. Trading systems we build store every order, fill, cancel, and replace as an event — reconstructing a portfolio's state at 14:32:17.213 on a Tuesday is a feature, not a debugging exercise. Healthcare and fintech clients use it because regulators want a complete history of every record change.

For a typical SaaS platform, we usually recommend against event sourcing the entire system — but we do recommend event-sourcing the parts that genuinely benefit (billing ledger, audit log, agreement signatures) while keeping the rest as plain Postgres. The mix is usually right. Book a call if you want a 30-minute review of whether your system actually needs it.