Systems/Intermediate · about 50 min · 7 stages
Design a Dropbox-Style File Sync Service
Design file storage that survives café Wi-Fi, laptop crashes and two devices editing offline: move large files without restarting, publish metadata only after its bytes are durable, and let every device catch up without polling the whole account.
The situation
A cloud drive keeps a user's folders available on their laptop, phone and browser. A desktop client watches local files, uploads changes, and downloads updates made on other devices. Users can share folders, work offline, rename and delete files, and restore earlier versions.
The service has 8 million daily active users and 400 million stored files. On a busy day users change 20 million files. Most are small documents, but a few are multi-gigabyte videos. Many clients disconnect mid-transfer; a laptop may be offline for weeks and must catch up when it returns.
The first version sends each whole file through one API request, then writes a row with its path and storage key. A timeout makes clients start over. Two devices editing the same file can silently overwrite one another, and the server sends every client a full folder listing after any change.
This is an original practice design. Public Dropbox engineering posts inform a few specific trade-offs; the workload, APIs and architecture below are assumptions for the exercise, not a description of Dropbox or Google Drive internals.
What it has to do
Functional
- Upload, download, rename, move, share, delete and restore files.
- Sync changes to every authorized device, including devices that reconnect after weeks offline.
- Resume an interrupted large upload and fetch only missing content blocks.
- Preserve both versions when concurrent edits cannot be safely merged.
Non-functional
- A completed file version never points to content that has not been durably stored.
- A retry cannot publish a duplicate version or apply a rename twice.
- An ordinary change reaches online devices within a few seconds; reconnecting devices can page through all missed changes.
- Revoking access prevents new reads promptly, including reads through previously issued download links.
- One account with many files or devices does not create unbounded work for other accounts.
Constraints and assumptions
- 8 million daily active users; 400 million files stored; 20 million changed files on a busy day.
- Small documents are common; the long tail includes files several gigabytes in size.
- Clients can disappear between any two requests and may return with stale local state.
- The team can operate a relational metadata database and a durable object store; exact vendors are open.
- A changed file averages 2 MB after compression; 20 million changes is about 40 TB of new bytes before deduplication and replication.
- A file version is an ordered list of immutable content blocks plus metadata; a block can be shared by multiple versions.
- The metadata journal is authoritative for file names, versions, permissions and sync cursors; notifications are only a wake-up hint.
- Native collaborative document editing is out of scope; this service syncs file versions, not simultaneous keystrokes.
The questions it prepares you for
- Design Dropbox or Google Drive file storage and synchronization.
- Design a cloud drive that resumes multi-gigabyte uploads over unreliable networks.
- How should a desktop client sync after being offline for several weeks?
- How do you handle two devices editing the same file while offline?
- Design file sharing with version history, deletion and fast permission revocation.
Read and practise next
From the source
- How Dropbox built itMetadata and immutable file blocks
Concepts to know first