Event sourcing without fear: when it pays off and when it doesn't

Event sourcing has a bad reputation. When people hear the term for the first time they picture complex systems, expensive migrations and teams that need months to understand a new concept. The reputation is not entirely undeserved — but it is mainly a problem of misapplication.

In many cases event sourcing is introduced as an architectural philosophy rather than a persistence strategy for a specific problem. That produces systems that make simple things complicated, because every update is turned into an event whether it fits or not.

What event sourcing really is

Event sourcing does not store the current state as the primary truth. Instead it stores the changes that led to that state: events. The current state is a projection of those events.

That difference is valuable above all in three situations:

• Audit and traceability: Every change is recorded, and who did what when can be reconstructed — not as an add-on, but as the core of persistence.
• Temporal questions: What was the state yesterday at 2 pm? How would the system have behaved if event X had not occurred?
• Complex domains: When the business itself consists of events — orders, payments, approvals, deliveries — an event stream is often the more natural representation than a table with the latest state.

When it pays off

The classic case is a business system whose state emerges from a chain of business events and whose history must not be lost. A real-world example: a payment service provider that has to record every authorisation, booking and chargeback attempt. A classic CRUD model would either invent a separate audit table or overwrite the current state and keep the audit as an attachment. Event sourcing makes history the primary truth.

Another good case: systems that need several read models from the same data. Because state is projected, a team can build multiple views on the same event source without reinventing the persistence layer.

And finally: domains where the business thinks in events. When business and engineering jointly create an event model, the step to an event-driven system is often smaller than expected — because the language already matches.

When it does not fit

The most common misapplication is a system that mainly manages data where the current state is enough and the history has no business relevance. User profiles, product catalogues, configuration data — here event sourcing becomes a burden without adding value.

Another poor fit: a team with no experience in eventual consistency, asynchronous communication and distributed systems. Event sourcing amplifies every one of these aspects. If a team struggles to design a good database schema, they will not be happier with event streams, projections and consistency models.

Then there is the big-bang migration: a monolith that has been running for ten years is to be completely moved to event sourcing. That is usually not a technical decision but a political one. It is expensive, long and risky. A better approach is a guided modernisation in slices, introducing event sourcing only where it really fits.

EventSourcingDB as a pragmatic foundation

Once you choose event sourcing you need a database that natively supports the model instead of rebuilding it on top of a relational store. EventSourcingDB from the native web is exactly that: a database built around the event stream, with support for projections, subscriptions and replication.

KAIHITO uses EventSourcingDB where the domain is event-driven and where operating an event-sourcing solution in-house would be too heavy. Combined with a clear event model and a defined ownership structure, it lets you build a system that can be operated and evolved without the team becoming a specialised framework expert.

When an event model is enough

Not every initiative needs event sourcing as persistence. Often it is enough to model the business as an event stream — as a shared language between business and engineering. An event modeling sprint brings that language to the table without committing to a technical infrastructure immediately. If it later turns out that the history of the data really matters, the path to event sourcing is already prepared.

Short version

Event sourcing pays off when history, audit and temporal questions are central to the business. It is not a generic architecture improvement and not an answer to unclear domains. Used where it fits, and operated with a clear event model and an event-native database such as EventSourcingDB, it gives traceability and flexibility. Used everywhere, it buys complexity without value.