The idea here: saving original stream of data events (insert/append only) to keep all data,
instead of doing updates of db records and keeping only the latest state.
Then the latest state can be re-calculated by "replaying" events.
As usual, the implementation "details" matter.
Postgres JSONB was mentioned as a powerful option for this kind of data storage
and derivative systems based on it, like Marten and Wolverine
.NET Rocks! Event Sourcing with Hannes Lowette (podcast)
"How can event sourcing help your applications?... helping developers utilize event sourcing patterns to build scalable applications. Hannes discusses moving away from the old habit of decomposing data from objects into rows, columns, and tables, as there's no reason to save that disk space anymore. Storing objects as event streams means you can always generate relational data if needed, but things run faster and scale better in the streams."
Event Sourcing (//learn.microsoft.com/)
The Event Sourcing pattern defines an approach to handling operations on data that's driven by a sequence of events, each of which is recorded in an append-only store. Application code raises events that imperatively describe the action taken on the object. The events are generally sent to a queue where a separate process, an event handler, listens to the queue and persists the events in an event store. Each event represents a logical change to the object, such as AddedItemToOrder or OrderCanceled.
