Understanding EventSourcing

What is this book about?

Martin Dilger's Understanding EventSourcing is a deep dive into event sourcing as an architectural pattern — what it is, why it exists, and how it solves problems that traditional CRUD-based systems create for themselves over time. The book doesn't just explain the mechanics of storing events instead of current state; it walks you through the mindset shift that event sourcing requires, and why that shift matters.

It covers the full landscape: the limitations of the CRUD approach, how event sourcing fundamentally changes your relationship with data, the role of CQRS as a companion pattern, projections, event stores, and the practical trade-offs you'll face when adopting this in a real system. Dilger is generous with examples and doesn't shy away from the hard parts — he addresses complexity honestly instead of pretending event sourcing is a silver bullet.

Who is this book for?

I'd recommend this book to developers who already have some meaningful experience building software products — especially if you've worked on a codebase that grew large enough to start fighting back. You know the feeling: the database becomes the bottleneck, the models become bloated, every new feature feels like surgery, and you start questioning whether software was supposed to be this painful.

If you've been through that, this book will feel like someone finally naming the problem you've been living with. And more importantly, it will show you a different way.

That said, if you're just starting out and haven't yet experienced the pain of a large, tangled CRUD system, some of the motivation might not land as hard. You'll still learn a lot, but the emotional resonance — the "oh, so THAT's why everything felt wrong" moment — comes from having lived through the problems first.

Personal opinion — is it worth it?

This one is truly special to me. It completely changed the way I look at software.

When I read it, I was working on a product that suffered from everything the book warns about. We had a classic CRUD system that had grown beyond what that pattern could comfortably handle — tangled state, impossible-to-trace bugs, features that required touching half the codebase. Reading Dilger's explanation of why this happens felt like a diagnosis for a disease I'd been fighting without knowing its name.

It felt liberating — to learn that there was a better way of building software, and that the frustration I'd been feeling wasn't a personal failing but a systemic one.

The book gave me a new lens for thinking about data, about state, about what it really means to "save" something in a system. And once you see software through that lens, you can't unsee it. Every design decision starts to feel more intentional.

This is one of my favourite books on software, full stop. If you care about building systems that age gracefully instead of collapsing under their own weight, read it.

Difficulty

The book is not particularly hard to read — Dilger writes clearly and the examples are well-chosen. But I do think you need a certain level of experience to fully appreciate what he's teaching. The concepts themselves aren't complex, but understanding the why behind them requires having felt the pain of the alternative.

If you come in with a few years of backend experience and some battle scars from working with large systems, it'll feel like the right level of challenge — stimulating without being overwhelming.

The score

5 / 5

A book that fundamentally changed how I think about building software. It gave me the vocabulary and the framework to understand problems I'd been struggling with for years. One of those rare reads where you finish it and immediately want to go refactor everything you've ever built.