Event Sourcing Pattern?-?Distributed Design?Patterns

Most systems that we work with on a general basis, require the latest state of the system and we use CRUD operations to keep the system at it’s latest state. However, there are systems that require temporality, which means your system doesn’t just need the latest state, but also can need the state at a particular point in time or needs to rebuild a new state/parallel system from its past states.

Event Sourcing

Event Sourcing is a pattern that suggests storing the history of all changes made to an application’s data as a sequence of events. Rather than storing the current state of the data, Event Sourcing stores the sequence of events that led to that state. In other words, instead of storing the result of each operation, we store the operation itself.

How does Event Sourcing?Work

Event Sourcing is based on the idea that every change to the data should be recorded as an event. These events are stored in an event store, which is a database specifically designed to store events.

When an operation is performed on the data, instead of updating the current state of the data in the database, an event is created that describes the operation. This event is then stored in the event store.

When we want to retrieve the current state of the data, we simply “replay” all of the events in the event store, starting from the beginning. This gives us the current state of the data.

Advantages of Event Sourcing?-

1. Audit Trail: Since all changes to the data are stored as events, we have a complete audit trail of what happened in the application, and when.
2. Separation of Concerns: Event sourcing separates the concerns of data storage and business logic. It allows developers to focus on building the business logic without worrying about how the data will be persisted.
3. Time Travel: Since we have the complete history of changes, we can easily “replay” the events to see what the data looked like at any point in time. This can be incredibly helpful when debugging issues or analyzing trends.
4. Scalability: Since we are only storing the events, we can easily scale out the write operations. This means that we can handle a large number of writes, through multiple consumers, without having to worry about performance issues.
5. Flexibility: Event Sourcing allows us to easily add new functionality to the application by simply adding new event types. This is because the business logic of processing events is decoupled from the events storage.

Disadvantages of Event Sourcing?-

1. Increased complexity: Implementing event sourcing can be more complex than traditional approaches due to the need to manage event streams and reconstruct state. Unless your application genuinely has use cases for temporal queries, Event Sourcing is not a preferred approach.?
2. Higher storage requirements: Event sourcing typically requires more storage compared to traditional approaches since all events must be stored and retained for historical purposes.
3. Querying can be complex: Querying event data can be more complex compared to traditional databases since you’ll need to reconstruct the current state to query the current state. Generally this is avoided by maintaining a different datastore constructed from Event Source which only persists the latest state.

Caveats with Event Sourcing?-?

In the event sourcing pattern, the event log is the source of truth for the system’s state. As events are stored in the log, they represent the changes made to the state over time. Each event has a specific structure that includes fields such as event type, timestamp, and payload data.

Managing changes to the event schema involves ensuring that the event log remains consistent and backwards compatible with previous versions of the schema. This is important because any changes to the event schema could potentially break existing code that relies on the old schema.

One approach to managing changes to the event schema is to use versioning. This involves assigning a version number to each version of the schema. When a change is made to the schema, a new version is created and events are written to the log using the new schema. Old events are still stored using the old schema, but new events are stored using the new schema. This allows existing code to continue to read and process events using the old schema, while new code can read and process events using the new schema.

One area where you might see Event Sourcing in action is Version Control as it generally requires you to “time-travel” to a particular state and apply actions/commits.

This brings us to the end of this article. Event Sourcing is a pattern that offers several benefits over the traditional approach to data persistence. By storing the history of all changes as a sequence of events, we have a complete audit trail, the ability to “time travel” to any point in time, scalability, and flexibility. Hope you gained something from this post & feel free to post comments on any doubts you might have and I will be happy to discuss them!

Thank you for reading! I’ll be posting weekly content on distributed systems & patterns, so please like, share and subscribe to this newsletter for notifications of new posts.

Please comment on the post with your feedback, will help me improve!?:)

Until next time, Keep asking questions & Keep learning!