What is Event Sourcing?
Event Sourcing is a way of creating systems based on event processing.
It is a real “buzzword” in the IT industry and a solution that brings many benefits, for example:
- easy scaling of applications, by distinguishing between Command and Query (in combination with CQRS) and asynchronous processes,
- full “history” of changes in aggregates, the so-called auditability,
- restoring the application state at a certain time.
With Event Sourcing, as with any buzzword, there are also inextricably linked a lot of facts and myths, which today we would like to bring closer and dispel. All this to show that Event Sourcing is not as scary as it is painted. Let’s get started.
The facts and myths about Event Sourcing
1. Event Sourcing is difficult
Event Sourcing is not difficult. It is just different. The basis for understanding and modeling the world here are the events that take place in it, and that affects both objects and relations between them. The emphasis here is on understanding business processes. Event Sourcing, therefore, requires a change in thinking and looking from a different perspective.
2. Event Sourcing is interesting but impractical
Business processes also involve “storytelling”. Therefore, it is a good idea to model them as events, because they’re a good reflection of the business process. It is not only a very interesting idea but above all and contrary to popular opinion, a practical one because it allows for maximum simplification of project communication. By relying on events and storytelling, Event Sourcing is simply closer to the real world. Proof? AddedElementToBasket, Accepted Order, IssuedProformaInvoice, Paid, IssuedInvoice, SentOrder. You could not report this sequence of events in a simpler way.
3. Event Sourcing requires the use of CQRS, Domain Driven Design and other fancy patterns
Both Event Sourcing, Domain-Driven Design (DDD), and CQRS focus on understanding business processes and modeling them as faithfully as possible in our software. Thanks to their application, IT systems work better and are easier to maintain. All of the abovementioned methodologies are perfectly compatible with each other, but what is crucial, their combined use is not obligatory. It falls into the category of “nice to have” rather than “must-have”.
4. Two databases are needed for Event Sourcing, one of which must be Mongo
Event Sourcing is not linked to a specific way of storing data. The key to understanding it is that the event log is the source of truth. Only the detailed description of events (referred to in point 3) will allow us to obtain current user data. We apply events one by one, from the oldest to the newest one. This process is called aggregation. The resulting state of the object is called projection. Each event can be saved as a row in the “Events” table, and the projection as a row of events in a standard relational table. Separation of the write model from the read model guarantees more optimization possibilities and logical separation. Two databases are unnecessary for all this – yes, you can use them, but it is not required at all. Just like using Mongo for this purpose.
5. Event Sourcing requires Eventual Consistency and a Kafka or RabbitMQ event bus
Eventual Consistency is a guarantee that if we have made any changes, sooner or later, they will be applied. We do not know when exactly, but we do know that it will happen. Event Sourcing, in theory, requires Eventual Consistency, just like any other storage. However, events can also be stored in a relational database, so contrary to popular opinion, we do not need Eventual Consistency at all. What is more, if we don’t need to send these events further (e.g. to other services/modules), we also don’t need to use event buses such as the already mentioned Kafka or RabbitMQ.
6. Event Sourcing has performance problems
Event Sourcing is as efficient as the storage it has underneath.
What is more, it has 2 of basic assumptions related to storage:
- events are immutable,
- you cannot change the past you can only interpret it differently – events are added one after another, just like in a queue (append-only).
Thanks to these assumptions, storage can be optimized for a situation where we never do “random record updates”.
That allows the event table to work faster, because:
- there will only be inserts at an end,
- updates will never be included in it,
- the read will be done only with a key.
That is why Event Sourcing should not only be not slower but can be even faster than traditional solutions
7. Event Sourcing is difficult to maintain
Event Sourcing is not childishly simple, but which software is not difficult to maintain? Probably only the one that has not reached the production stage. The problems of migration and data consistency in distributed systems are complicated, but they do not get any simpler when using classic/relative solutions. In systems based on events, they simply come to light sooner.
Summary
As you can see – Event Sourcing has many advantages, but, like everything else, it also has its limitations and some characteristic issues you need to keep in mind, depending on the specifics of your particular project. This approach has its supporters and opponents. It can bring many benefits when you use it wisely.
