Ask HN: How do you architect a versioning system? | Hacker News Reader

Ask HN: How do you architect a versioning system?

2 pointsbostonvaulter23 comments

A semi-common feature that many SaaS products have the ability to store and restore older versions of a "document", e.g. Google Docs, Notion, Figma. However, most of these products feel like they have a document rather than db-based model that operates on multiple tables. For example Figma has a great article about how their documents are actually files rather than database rows: https://digest.browsertech.com/archive/browsertech-digest-figma-is-a-file-editor/

So for a system that is built on top of multiple database tables to load a single page/document how would you go about creating and storing a version history for all the related tables? Or would you use a non-db approach somehow?

(oh hey, author of that article here :))

This is something I've been thinking a lot about as well. A cool approach I've been experimenting with is using a CRDT for the underlying document data, and taking snapshots of the logical clock that correspond to version numbers. If you don't garbage-collect the CRDT, you can then restore the value based on the logical clock.

The CRDT itself can be persisted to S3 or similar, as in that article. We’ve been working on this in the open, so you can follow along: https://y-sweet.dev/

Ah, thanks for the link. Yeah a CRDT would be pretty nice although there's soo many constraints that you accept with one.

Thanks for the link to y-sweet! That's pretty sweet! ;)

If you just need to restore older versions of a (non-text) doc and don't need to support things like diff and merge, a handy approach is to store all the steps needed to create the doc, same as you would to implement undo/redo and allow "tagging" the operation stream to create your versions.

There are a lot of ways to optimize this sort of thing in practice so it runs reasonably, but that's an exercise for the implementer.

Reply on news.ycombinator.com