Event Sourcing on

Lesson 3: CQRS + Event Sourcing Together — When the combination makes sense

Sun, 24 Nov 2024 00:00:00 +0000

CQRS and event sourcing are often discussed together, presented as a single package, and that conflation is responsible for a lot of unnecessary complexity in codebases that should have stayed simple. I’ve seen teams adopt both because they read a blog post, without being clear on why they needed either. I’ve also seen teams who should have used both and instead built elaborate workarounds that were essentially CQRS and event sourcing with worse ergonomics. The question isn’t “should I use CQRS and event sourcing?” — it’s “do I have the specific problems these patterns solve?”

Lesson 2: Projections and Read Models — Build any view from your event stream

Fri, 13 Sep 2024 00:00:00 +0000

After I shipped the event-sourced account system, the first question from the product team was: “Can we have a page that shows all accounts that have been dormant for more than 90 days?” In a traditional system, this is a query: SELECT * FROM accounts WHERE last_activity < NOW() - INTERVAL '90 days'. In event sourcing, there’s no last_activity column — there’s an event stream. My first instinct was to query the event store directly, find the latest event per stream, and filter. It worked. Then they asked for the top 100 accounts by balance. Then active accounts by geography. Then a real-time dashboard with all of the above simultaneously. Querying the event store for each of these is either very slow or very complex. The answer is projections — pre-computed read models built from your event streams.

Lesson 1: Event Store Design — Append-only logs that are your source of truth

Sat, 29 Jun 2024 00:00:00 +0000

My first encounter with event sourcing was a financial system that needed a complete audit trail. The business requirement was clear: every change to an account balance had to be traceable — who changed it, when, why. The first approach was an audit log table alongside the main accounts table. We’d write to both in a transaction. Within six months, the audit table was out of sync with the accounts table. Bugs in the dual-write logic, a migration that updated account records without touching the audit log, a direct database fix that bypassed the application layer. The audit log was nearly useless. The core insight I eventually arrived at: the audit log shouldn’t be a secondary record — it should be the primary record. That’s event sourcing.