(2) Event Sourcing Pattern - Distributed Design Patterns | LinkedIn

Tags

Top Highlights

• 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

• Event Sourcing is based on the idea that every change to the data should be recorded as an event.

• 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.

• 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

• 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.

• 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.

• 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.

• 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.

• 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.

• 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

• Higher storage requirements: Event sourcing typically requires more storage compared to traditional approaches since all events must be stored and retained for historical purposes.

• 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.

• 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.

• 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

• 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