What they don’t tell you about event sourcing

Event sourcing and CQRS gained a lot of popularity recently. The advantages are obvious and they share a very peculiar symbiosis with the current tech state of the art, making them very relevant. However, after working for several years with them in production there are several caveats that one should care for.

If you are not familiarized with event sourcing it comes down to instead of saving the application’s last state, to model it in the form of a sequence of immutable events. Changes to the state are reflected by saving the event that triggers that change instead of changing the current state. Processing each event in the stream will produce the latest state of that entity. You can find a detailed explanation by Martin Fowler here.

At first glance, it seems a terrible idea. Since each entity is represented by a stream of events there is no way to reliably query the data. I have yet to meet an application that doesn’t require some sort of querying. This is especially evident in data-intensive applications where much of the business value relies on analyzing the data. This difficulty by itself makes event sourcing unsuitable for most applications and only relevant for very isolated and specific use cases.

That’s when CQRS comes in. CQRS (command query responsibility segregation) describes the concept of having…