Event Sourcing and CQRS Are Not An Overkill

Event sourcing is often dismissed as an overkill, but in reality, it mirrors how facts unfold in almost every business domain.

It’s an approach that I’ve learned to love over time.

Event sourcing captures the full history of what actually happened, rather than idolising just the current state. Many systems overlook the importance of preserving past events, focusing only on present data. In doing so, they miss out on a gold mine of valuable information.

Stored events provide the foundation for deep analysis, auditing, and informed decision-making. They allow us to understand how the system evolved and to drive meaningful improvements based on that insight. In a way, event sourcing is paving the path for significant innovation and optimisation.

Take an e-commerce order management system as an example:

In a traditional system without event sourcing or CQRS, the order status is updated directly in a single database table. You only see the current state: “shipped,” “delivered,” or “cancelled.” The detailed history of how and when each status changed is lost or hard to reconstruct.

Obviously, wise developers try to keep a history of changes without event sourcing, but these solutions are almost always tailored to specific cases.

In contrast, an event-sourced system records every event: “order placed,” “payment confirmed,” “order packed,” “order shipped,” and so on. The generality of this approach opens many possibilities beyond just keeping history (auditing, complex analysis, rebuilding of state from events).

Similarly, CQRS may seem convoluted, but it reflects real-world workflows by distinguishing between the responsibility of updating data and reading data, optimising both independently. This, again, opens a world of possibilities.

So, yes, there’s a common temptation to dismiss event sourcing and CQRS as only applicable to massive, complex architectures (“We’re not Amazon!!”), but a deeper look reveals that even small-scale systems stand to gain from these approaches.

Preserving the history of changes and separating concerns in data handling improves transparency, maintainability, and the ability to evolve the system gracefully over time.

In my view, it’s not premature optimisation.

Originally posted on LinkedIn.