10.6 Event Sourcing
Store data as a sequence of changes to preserve historyThis pattern is based on Event Sourcing by Fowler [184], later by Richardson [20, p. 184, 185], [3, p. 434], Microsoft [186] and Deenadayalan [187].
10.6.1 Context
See the context defined in 10.2.1. Furthermore, the application would benefit from storing the entire history of state changes due to one of the following reasons [184].
The history needs to be (or would benefit from being) auditable or analysed, and as such there needs to be a high level of trust in the log
It needs to be able to reconstruct the state at any given time or analyse the impact of changes
The application would benefit from running in-memory due to performance requirements
10.6.2 Solution
Implement the Command and Query Responsibility Segregation (CQRS) pattern. On top of it, store each event change as a separate record in an append-only event store (see fig. 33).
10.6.3 Potential issues
Working with an event-sourced system may be unfamiliar and thus have a learning curve. Communication with external system needs to be carefully handled if needing to replay the history, such as deterministic identifier generation. Schema evolution and deleting data can also be challenging.
10.6.4 Example
ExampleEshop employs a backend system to manage products. On change, this system triggers a rebuild of the read-only database replicas. Since rebuilding the whole database is expensive, the system only sends the changes to the replicas. However, an issue arises when a replica fails, as without a history of the changes, it is hard to tell which changes have already been applied, and a full rebuild has to be triggered, prolonging the downtime.
To address this, the system uses event sourcing, as it is already using CQRS. Each replica holds the event it has processed last, and when it fails, it only needs to request the events it has missed. This way, the system can recover much faster. This also has business benefits, as the system can now provide a history of changes, which can be used for analytics or to recover from user errors.
Another point where the system uses event sourcing is in the order processing orchestrator. This allows for easy transactional messaging between services, as the orchestrator can simply replay the events if a service fails, and simplifies debugging in the event that a transaction fails, which is important as a problem in the order processing can result in significant financial losses.
10.6.5 Related patterns
- Command Query Responsibility Segregation (CQRS) can facilitate event sourcing by splitting read and write operations beforehand (see § 8.5)