When (and Why) You Should Not Use Event Sourcing?

Event sourcing is powerful when you really need to track the history of state changes in your application. But it comes at a cost: added complexity, storage overhead, and operational challenges. Keep your stack simple whenever possible—think twice (or even thrice) before adopting it.

What Event Sourcing Actually Means

As Martin Fowler defines it:

“The fundamental idea of Event Sourcing is that every change to the state of an application is captured as an event object, and these events are stored in sequence for the full lifetime of the application state.”

If you’re new to the concept, I highly recommend checking his full article for a complete explanation. The goal of this post isn’t to re-explain event sourcing, but to clarify when not to use it.

Should You Avoid Event Sourcing Completely?

Not necessarily. Event sourcing has its place, but it is more complex than simply updating values in your application.

Instead of just overwriting state, with event sourcing you must:

1. Identify every state change in your application.
2. Represent that change as a specific event.
3. Persist those events in order.
4. Rebuild (“reconstitute”) the current state of your system from the event history.

This adds significant mental and technical overhead. If you don’t need an audit trail or historical replay of events, you’re often better off avoiding it.

Does CQRS Mean I Must Use Event Sourcing?

No. While CQRS (Command Query Responsibility Segregation) and event sourcing often appear together, they are not inherently tied. Many frameworks couple them, but you can absolutely use CQRS without event sourcing. Choose based on your problem domain, not on trends.

When Event Sourcing Shines

Consider event sourcing when you need to:

• Track state transitions (e.g., order lifecycles, shipment tracking, approvals).
• Build event-driven domains (e.g., financial transactions, workflows).
• Record user activity (e.g., detailed tracking of user actions on a website).

When Event Sourcing Is Overkill

You should probably avoid it for:

• Simple shopping cart updates.
• Drafts, quotes, or temporary data.
• Product or service records (unless historical price/version tracking is critical).
• Form submissions and similar short-lived data.

Final Thoughts

Event sourcing is one of those patterns that looks elegant in theory but can cause time sinks, frustration, and unnecessary complexity when misapplied.

👉 Adopt it only when your use case demands a complete event history—not just because it sounds cool or a framework supports it.
👉 A mindful decision upfront can save your team months of technical debt later.
```