Event Sourcing

Event Sourcing is an alternative approach to storing information where change events are retained rather than being discarded after their corresponding update to program state. The “current state” of the program then becomes nominal state—state that is actually just a derivation of the event stack. Event Sourcing should then be used when the entire history of the state of the program must be retained for some purpose, be it a reinterpretation or an audit.

Reinterpretation

During a reinterpretation, the nominal state may change dramatically from new information, such that all prior events are considered relevant. Event sourcing is special, as it retains the maximum possible information from the events that have entered a program. This may appear to violate the principle of Minimal Essential State, but if Event Sourcing is found to be necessary, then it is more accurate to say that all information was essential. The only possibility to retain more information is to actively capture said information, such as saving timestamps alongside the events, or adding another required input to a form.

Since the nominal state is a derivation of the event stack, it may be defined reactively using a declarative framework. To do so in React, you would only need to store the events in React state as apposed to their interpretation, leaving the nominal state to be computed as part of the render function. It is also possible to abstract the code base from the Event Sourcing by storing the events secretly, as with LogRocket’s storage of Redux events using middleware.

Audit

An audit is an after-the-fact analysis of events outside the normal operation of the program. An Event Source audit may be performed during the investigation of a catastrophic error, for an analysis of a security breach, or to study the user experience, or any other investigation where all events may be of interest. Audits are distinct to reinterpretations in that they are not part of the defined operation of a program. Where a reinterpretation happens automatically, an audit involves human intervention, though this may lead to a manual reinterpretation if a correction is found to be necessary.

What Event Sourcing Isn’t

Retention of input events to allow for Reversibility is not necessarily Event Sourcing. If a reversal (undo) has the potential to lose the reverted input, then it is not Event Sourcing. Event Sourcing would need to retain both the reverted input event, and the reversal event, such that even reversals do not lose information.

State Change as a Filter is also not necessarily Event Sourcing. If a filter may be permanently deleted with no record of it having existed then the filters are not Event Sourced. Both the existance of the filter and the deletion would need to be retained as events, just as with all other state changes.