Design the versioned storage layer behind a file-and-document collaboration product: every save creates a new immutable version, users can browse the full history of a file, restore an old version, and storage is deduplicated so a thousand tiny edits do not cost a thousand full copies.

Operating context. A save writes a new version and advances the file's head pointer; older versions stay readable forever (until a retention policy thins them). Reading the current version is the overwhelmingly common operation and must be fast; reading deep history is rarer and may be slower. Content repeats heavily — re-saving a large file after a one-line change, or many users storing the same attachment — so naive full copies would waste most of the disk. Restoring an old version creates a new head; it does not erase the versions in between.

Out of scope. The editor and diff-rendering UI, real-time collaborative editing / conflict resolution, sharing permissions and access control, and full-text search over file contents. Assume an auth layer authorizes each request and hands you a file identity.

What to produce. A high-level architecture covering: the split between version metadata and content bytes; the content-addressed, deduplicated storage scheme (chunking, hashing, whole-object vs delta); the blob tier and hot/cold placement for very large files; the restore and history-read paths; and the retention/garbage-collection story that reclaims space without breaking a live reference. Sketch the components and the flow of one save and one restore; we will probe specifics in checkpoints.