I've got a requirement to create a data structure that allows for users to view revision history. Not just the history of a table, but the history of the entire structure at a given point in time.

A pure database solution would involve massive recreation of records. For example - say I'm building a check sheet. Sheets have multiple to-do items, to-do items can be assigned to multiple sheets. It's a simple many to many relationship.

Now say I edit the sheet to remove an item. To maintain revision history, I have to recreate the check sheet and recreate its relationship to the to-do items, minus the one that got removed. And editing a to-do item would cause me to have to recreate every check sheet that references it.

So the solution I'm thinking about is to record the actions that are performed against the check sheets, and when a user wants to specific revision, replay all the changes against an object graph in my code.

Is there an event driven data pattern out there? Is this the best way to do this? I'm just looking for input from anyone who has had to work with revision history for massive data structures before.

  • 2
    I believe what you are looking for is called event sourcing
    – yitzih
    Apr 19, 2019 at 1:52

1 Answer 1


Your question reads like an introduction to Event Sourcing, which I think is in fact the best approach for your problem.

In principle it works just as you describe: To load an object, you start with an empty/uninitialized version of your object and then apply all changes that have been made to it in sequence.

In practice this is also the way you should implement it. However, given that your objects are 'massive', the number of changes you need to apply may also become very large - and thus take too long.

When this becomes a problem, you can additionally store snapshots of your object's state at regular intervals and then only apply the remaining events.

  • 1
    You may want to consider storing "undo" records (reversing the state changes) rather than "redo" records. This is used in conjunction with storing the snapshot of the latest version because that's the most commonly viewed version of the object.
    – Egret
    Apr 21, 2019 at 18:16
  • @Egret That's an alternative to consider, but then you immediately have to find a way to store your (possibly complex) model on each operation. With ES it's easier to gradually add complexity only when needed. You also get a nice revision history for free and it'll be easier to build additional modules (e.g. analysis) on top of the event stream.
    – doubleYou
    Apr 30, 2019 at 16:54
  • I tend to agree. I was thinking about undo and redo logs in the database (which is a somewhat extreme example). But even there the undo logs are primarily used for uncommitted transactions, which isn't likely to be an issue here.
    – Egret
    May 4, 2019 at 20:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.