Event Sourcing pattern

1. An application design where state changes are logged as Time ordered sequence of state changes
2. Capture all changes to an application state as a sequence of events.
3. Instead of storing just the current state of the data in a domain, use an append-only store to record the full series of actions taken on that data. The store acts as the system of record and can be used to materialize the domain objects. This can simplify tasks in complex domains, by avoiding the need to synchronize the data model and the business domain, while improving performance, scalability, and responsiveness. It can also provide consistency for transactional data, and maintain full audit trails and history that can enable compensating actions.

Reading material

1. https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing
2. https://martinfowler.com/eaaDev/EventSourcing.html
3. https://microservices.io/patterns/data/event-sourcing.html
4. https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/service-per-team.html

Event Sourcing vs CRUD

Source: Linkedin https://www.linkedin.com/posts/samhatoum_crud-is-inferior-to-event-sourcing-es-activity-7316872214304210945-uihy

Sam Hatoum

Building on.Auto

CRUD is inferior to Event Sourcing (ES).

Your app’s data is a story. CRUD is like reading the last page and burning the book!

Event Sourcing is the full narrative, every twist and turn stacked into a rich, unbroken tale.

The AI future is starving for those plot twists—every event is a training goldmine. Yet, devs still cling to CRUD, throwing valuable data out the window either because they don’t know about Event Sourcing, or because they had a bad first date with it.

CRUD is LOSSY, and AI is DATA HUNGRY.

The typical arguments against ES go something like this:

• ES feels too steep a climb to get started with ease.
• ES seems overly complex for simple, everyday use cases.
• ES can lag when reconstructing state for real-time needs.
• ES querying feels clunky next to straightforward CRUD.
• ES bloats storage by capturing every single event.
• ES schema changes turn into a versioning headache.
• ES confuses teams comfortable with classic DB setups.

These objections to Event Sourcing stem from outdated constraints and entrenched habits.

Historically, storage was costly, so CRUD optimized for disk efficiency by sacrificing rich history events— today however, storage is cheaper than your lunchtime burrito.

Universities and colleges still churn out CRUD-focused developers, not because it’s superior, but due to academic inertia, leaving grads unprepared for ES’s power.

Meanwhile, a massive industrial complex—tooling, frameworks, databases—has ballooned around CRUD over decades. And all industrial complexes naturally resist change to protect their ecosystem.

But here’s the kicker: the complexity of scaling CRUD systems dwarfs ES’s perceived drawbacks.

Why?

First, CRUD’s single-state model is not concurrency friendly, leading to messy locks or race conditions, while ES natively handles conflicts via append-only logs.

Second, auditing or tracing changes in CRUD requires bolt-on solutions, whereas ES’s event log naturally leaves an audit trail.

Third, scaling CRUD often requires denormalizing data or sharding, introducing maintenance nightmares—ES, with its immutable events, distributes and scales cleanly. You can independently scale the read and the write sides as they ALWAYS have different scaling profiles.

Finally, debugging distributed CRUD systems is a puzzle of incomplete snapshots and data forensics exercise; ES’s event streams offer a clear, narrative of historical facts, allowing you to easily replay production issues.

If you’ve hesitated to explore Event Sourcing, what’s really stopping you? the initial effort to learn something new? comfort with CRUD? or something else?

Why limit yourself to CRUD’s constraints, when the future of data lies in its history?

Opposing Comments

Brad Mongeon

Sr. Principal Software Engineer @ Globalization Partners

Event Sourcing can add unnecessary complexity and cognitive load depending upon how well it fits into your problem/solutions domain. There are many ways to keep that rich event data without doing pure event sourcing. At some point you often need to know the current state, so you need to be OK with eventual consistency with event sourcing. You can always emit the key events and be eventually consistent with them, while focusing on maintaining the current transactional state.

With the many different database types saying the choice is “CRUD” vs. Event-Sourced does not properly represent the choices. You could also consider a DB transaction log similar to an append-only log or use something like DynamoDB streams to maintain that rich event data.

There are a lot of assumptions in your statements. Plenty of domains will scale fine without event sourcing and will never need to scale to the degree you are discussing. I also think you can implement CQRS without Event Sourcing and handle high volumes. I am also wondering if you are thinking about transactional relational databases when you say “CRUD”, as there are plenty of other quite scalable options.

I am not sure what you mean by bolt-on. I am assuming if you are doing Event Sourcing that you will use an eventually consistent read-side data store of some sort. Is that bolt-on? That store would likely need to be used to determine the next change in state in some instances. I feel like you are talking about a matter of perspective and just shifting around complexity in a different way. Event-Sourcing is one solution to certain scaling problems but I do not think it is the only solution or necessarily the easiest. Though I have seen it be a fantastic solution for the right use case for sure.