File sync - every laptop is a replica

Why this design

"Design Dropbox" sounds like an upload form with a folder tree. It is actually a replicated database whose replicas are laptops that go offline for a week, whose writers are applications that know nothing about sync, and whose conflicts cannot be merged automatically because the data is a .psd. The question tests whether you separate bytes from metadata, whether you can make a 2 GB file with one changed paragraph cost one block of upload, and whether you can say exactly what happens when two offline edits meet.

What you will learn

• Why files are cut into 4 MiB content-addressed blocks, and how that one decision gives you delta upload, cross-user dedup and resumable transfers for free.
• Why the metadata journal and the block store are different systems with different scale, consistency and cost - and why a commit happens only after its blocks exist.
• Compare-and-set on a parent revision: the single rule that detects every conflict, and why it can only detect, never merge.
• Cursors and long polls: how 50 million idle clients learn something changed without polling a database.
• The client as a stateful replica with three trees - local, remote and synced - and why that local database is the most dangerous component on the board.

How to read this board

1. Press Play. LAPTOP A saves a file, the chunker finds the three changed blocks, and the commit goes to METADATA.
2. The missing blocks go to BLOCKS, which only stores, then the commit is appended to the journal.
3. LAPTOP B is woken by a long poll, reads the journal from its cursor and finds that it edited the same revision while offline.
4. Then read pages 1 to 6, and the DATA MODEL at the bottom.
5. Argue with the weaknesses on purpose: file-level conflicts, one ordered journal per shared folder, and a client database you cannot afford to lose.

Ask these before drawing anything

• Sync only, or also share and collaborate? Shared folders mean a namespace with many writers, which is where every hard problem on this board lives.
• How large can a file be? 50 GB video files decide whether resumable, block-level upload is a requirement or a nicety. Here it is a requirement.
• How long may a device be offline? If the answer is "indefinitely", the server must keep enough history to bring a 6-month-old replica up to date, or declare it too stale and force a rescan.
• What does a conflict produce? Silent last-writer-wins loses work. Conflicted copies keep both and annoy people. Pick one out loud.
• Is version history a product feature? 30 days of restorable versions means deleted blocks cannot be deleted for 30 days.
• Selective sync and placeholders (files that exist in the tree but not on disk)? It changes the client a lot and the server barely at all.

Functional

• A change on any device appears on every other online device of every member within seconds.
• Upload and download transfer only blocks the other side does not already have.
• Offline edits are kept and synced on reconnect; concurrent edits never silently overwrite each other.
• Restore any file to any version from the last 30 days, including deleted files.
• Shared folders: a namespace mounted into several users' trees with per-member permissions.

Non-functional

• Durability of committed data: 11 nines on the block store. A sync product that loses a file is finished as a product.
• Change propagation p95 under 5 seconds from commit to the other device starting its download.
• Metadata commit p99 under 200 ms; it is the only synchronous step the user waits for.
• Clients are hostile environments: crashes, full disks, clock skew of hours, antivirus locking files. The protocol must not trust device clocks for ordering.

Out of scope

• Real-time co-editing inside a document - that is the collaborative-editor board.
• Full-text search of file contents.
• Mobile camera upload, which is a one-way ingest and much simpler.