The core of the Event Sourcing pattern relies on an event store to preserve events. But what if we could add these events to a blockchain as they arrive? This approach would ensure that the events remain untouched and secure. The plan involves initiating typical blockchain mining, after which the event is incorporated into an “EventChain.”
One significant side effect of this process is that until mining is complete, the business transaction cannot be internally marked as finished. Given the typical duration of mining, this would likely become an offline task.
Ensuring Tamper Resistance
Organizations employing event sourcing often encounter challenges related to securing events. What if the database administrator for the event store manages to manipulate or delete events? In such cases, the replayed events and their resulting projections become invalid. Event chains offer a solution to this problem for conventional event stores.
Leveraging Distributed Infrastructure
For private event chains, where businesses aim to keep the chain and its events concealed, existing distributed systems and hosts can be utilized for mining. Hosts within your event store database cluster, event sourcing services, API hosts, cache cluster, and other geographically distributed resources can contribute to this process.
Addressing GDPR Challenges
Certain regulations require the removal of personal data from all data stores. In our context, this entails removing the related set of events from the event chain. Unlike the relatively straightforward process of deleting events from the event store, resetting the event chain when events must be deleted poses challenges, especially if numerous events have occurred after the concerned event(s). This would necessitate re-mining all subsequent events from the event’s point of removal to the most recent one. Given the extreme time and computational resources required for this operation, storing events containing personal data in the event chain is not recommended.
Snapshotting
As events from the event store can be replayed to reconstruct a specific state at a given time (“projections”), we can consider introducing “snapshots” to pinpoint a particular projection in time. These snapshots can be linked as child branches to the primary event chain tree, reducing the need for recalculating projections each time while ensuring the integrity of the projections themselves. Moreover, multiple child branches/trees can be established for various filters and conditions as needed.
