Event sourcing

Definition

In an ordinary database the value is overwritten when something changes. You are left with the current state and have lost the path to it. Event sourcing inverts this: the events are the truth, and current state is something you compute by replaying them in order. Nothing is overwritten, and the log can be read again.

That yields three properties that are hard to retrofit. You can recreate the state at any point in time. You have an audit trail without building it as a separate mechanism, because the log IS the trail. And you can run history through new logic, replaying what happened against a model that did not exist at the time.

In practice

In the power sector the pattern already exists, though not always under this name. Metering values are corrected after the fact: an estimated value is replaced by a read one, and a read one may be replaced by a corrected one. The settlement made last month must still be explainable from what was known then, not from what is known now. That is why versioned time series and traceability are a requirement in VEE work, and it is the same problem event sourcing solves. The common solution to the same problem is not event sourcing but versioned time series in a time series database: each value gets a version and the old one remains. That solves traceability without changing how the system stores state. Event sourcing goes further, by making the events the only source. The most tangible benefit is replay. Given a new model for condition assessment, you can run several years of actual events through it and see whether it would have caught a failure that occurred. A database holding only current state cannot answer that question.

Suggest a correction

Definition

In practice

See also:

You might also like