In the previous post, we saw how to create events based on commands. Why not update the database directly? Why do we need to go through an Event Store? Let’s talk a bit about the current situation… Currently, the majority of systems keep their data in a relational database common to several information systems. The reason for this centralization is simple: it is very easy to share common tables between the different systems. This convenience meets certain needs:
- Ease of maintenance of common tables
- Coherent intersystem information
- Reuse of information
This centralization also has disadvantages that are not negligible. If one or two systems use these tables, that is not a problem, but as soon as you add dependent systems, problems can begin to appear. Often, a new system has a need for information that is not covered by current data. Adding a column to the table will affect all systems that use it. In addition, this new information will be considered pollution for other systems. The amount of information to be carried over the network will also increase.
How to achieve the benefits of centralization without the disadvantages? This is where Event Sourcing is interesting. Considering the business field as a succession of events greatly simplifies the problem. Even though this list of events is distributed across multiple nodes, this is not a problem. Each event is written once and will not change anymore. If the node that contains the events has no more space, we can easily add storage without risk of losing the events we already have. To avoid the loss of events, we can use distributed storage methods such as MongoDB which makes it easy to add nodes to the cluster. In the next post, I will explain in more detail how to make your events evolve over time.
