Event Sourcing vs. Conventional Data Management

Building applications that are scalable and easy to maintain is the ultimate goal for us, Software Engineers. Event Sourcing, a paradigm that has been gaining a lot of hype in recent times, is one way to achieve this objective.

Event Sourcing is a concept that everyone has heard about, but the topic is often unknown, leaving many without a clear understanding of its principles and benefits. It disrupts traditional methodologies and revolutionizes application data management, opening up new design possibilities that were once unlikely.

Summary

Conventional Data Management
Event Driven Data Management
Summary
Conclusion

Conventional Data Management

Relational Database Management System

The conventional data management approach involves directly storing the current state of an application’s data at any given point in time. Storing these data points is the standard for most databases and systems; when the state changes, the new replaces the old and the old vanishes. Although this strategy is more straightforward and more practical to set up, it may fail to record the complete history of the application’s development up to that point.

Example of Conventional Data Management:

An Administrator creates a new User (Jane Doe). This is done by inserting a new record in the Users Table.

INSERT INTO Users (FirstName, LastName, BirthDate)

VALUES (‘John’, ‘Doe’, ‘1993-02-19’);

After inserting, the Users Table will appear as follows.

Now, consider a scenario where there was an error in the First Name of the user with ID 2, and the administrator wishes to correct this by updating the user’s first name. In this situation, an UPDATE statement would be executed.

UPDATE Users

SET FirstName = ‘Bob’

WHERE ID = 2;

This statement modifies the record with ID 2, assigning the new value “Bob” to the FirstName column. As a result, whenever we query the table, we will observe “Bob” in the entry with ID 2.

This database solution is suitable for most scenarios and delivers the expected functionality. However, difficulties emerge when we need to track changes in names, such as the transition from ‘John’ to ‘Bob’. The system lacks mechanisms for preserving historical data related to our dataset. There exist a few patterns and solutions that we could employ, like maintaining a history table or enhancing handlers with history-tracking behaviors.

However, these solutions aren’t inherent to the system, and incorporating these mechanisms could potentially introduce errors or suboptimal implementations. This consequently brings a risk of regression. Suppose we’ve indeed developed a robust system capable of capturing every change. This leads to another crucial question: How did we arrive at this point, and can we replicate that sequence of events? Now, attempting to introduce these mechanisms into an existing codebase can be quite a challenge, and this is where Event Sourcing comes into play.

Event-driven Data Management

Event Sourcing

The Event Sourcing design stands in contrast to the conventional data management approach. Instead of only storing the latest state, Event Sourcing captures and retains every change, action, or decision as an immutable event in a chronological log. These recorded events create a comprehensive historical record, documenting the entire evolution of the application over time.

By preserving the full history of data changes, Event Sourcing provides a detailed trail of past actions, offering valuable insights into the system’s behavior and facilitating thorough debugging and auditing processes.

Example of an Event-driven Data management:

Let’s consider the example from the conventional approach. An administrator intends to create a new user and subsequently needs to alter their name due to a miscommunication. Instead of recording the data in a row and later modifying the value within this row, an Event-Driven system will log two events: a UserCreatedEvent and an UpdateUserEvent. These events encompass all the necessary data for executing actions on the entity (fc1c0c5d-f62c-…).

So, now that we have the data stored, how does one go about querying that data? Let’s break down the process of querying an entity within an Event-Driven system. Initially, the events associated with a particular entity are retrieved from the Event Store. Following this, these events are replayed onto a model. It’s important to note that the model is technology-agnostic. When we mention “replaying onto a model”, we’re referring to the process of iterating through each event and applying them to the model.

The Model defines and encompasses the rules for interpreting each Event and constructing a state. This ultimate state comprises all the information of the Queried Entity.

By maintaining Events at the core of the system, a history log is established, enabling the capability to replay events. This abstraction provides the ability to engage in time travel and manipulate the system state to your benefit.

Summary

Data Storage:

Event Sourcing: Events are stored in a sequential manner, building a historical record of all significant changes in the application’s state over time.
Conventional Approach: Only the current state is stored, and the history of changes leading to the current state is often not explicitly captured.

Reconstruction:

Event Sourcing: The application’s current state can be reconstructed by replaying the sequence of events from the beginning up to the present moment.
Conventional Approach: The current state is readily available, but there might not be an easy way to recreate past states without additional tools or backups.

Conclusion

Event Sourcing is a game-changer for applications data management and it’s clear that this paradigm shift is revolutionizing the industry. Instead of solely focusing on the present state of data, Event Sourcing places emphasis on capturing the history and context of data changes.

Keep in mind that Event Sourcing is not a one-size-fits-all solution. It should only be adopted when truly necessary, as it comes with a cost – the cost of added complexity.

When designing a system, we recommend adhering to the principle of prioritizing simplicity and consistency over unnecessary complexity. Introducing Event Sourcing does bring an extra layer of complexity to your system, so make sure you have a solid rationale for doing so.

If you’re interested in implementing Event Sourcing, you might find Greg Young’s repository helpful.

Other sources:

More Resources

To learn more about Generative AI in an Agile environment, you can take a look at our insight: Agile Architecture, a key practice for embracing changes.

Thanks to our
Author

Daniyar T.

Event Sourcing vs Conventional Data Management