How would you design a file storage service like Dropbox?
874 views
66 of 106
1
The problem
Question presented to candidate:
"Design a file sync service like Dropbox. A user installs a client on a laptop and a phone; any file they put in the synced folder should appear on every other device within seconds, edits should upload quickly even for big files, and nothing should be lost if two devices edit the same file while offline. How would you build the client, the servers and the storage?"
What a strong answer should cover:
Block-level sync: split files into blocks (Dropbox uses blocks of up to 4 MB identified by SHA-256), upload only blocks the server lacks; this gives delta sync and deduplication, and a file becomes an ordered list of block hashes
Separate the block store (content-addressed, immutable, object storage) from the metadata service (namespaces, paths, revisions, block lists) and a notification service that tells idle clients to fetch changes
A per-namespace journal with monotonically increasing sequence numbers; each client keeps a cursor and pulls everything after it, which makes sync resumable and ordered
Commit protocol: the client commits "path now has these blocks, based on revision X"; the server answers with missing blocks or a conflict when the base revision is stale, and the client then saves a conflicted copy
Chunking trade-off: fixed-size blocks re-upload everything after an insert near the start; content-defined chunking keeps boundaries stable
Numbers: users, storage, commits per second, long-poll connections, block index size, and what breaks at 10x
Clarifying questions expected:
How many users and devices, average storage per user, typical file sizes?
Is real-time collaboration on the same document in scope, or only file sync?
Do we need sharing, version history, and LAN sync?
Code / implementation expected: Optional โ the design and the sync protocol come first; the examples compare chunking strategies and simulate the journal, cursors and a conflict.
file-storage
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Developers preparing for system design interviews. You know what a hash, a database and object storage are; nothing about sync engines is assumed.
Difficulty: Hard
Verified with: Node 22.22, Python 3.12, Go 1.24 and Java 21 for the chunking example; Node 22.22 and Python 3.12 for the journal example (identical output in every language). Dropbox facts are from Dropbox engineering posts, cited inline.
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the exact words an interviewer expects. Capacity numbers are worked from stated assumptions. All sync behaviour comes from running the examples; the Verified section quotes the full output.
1. Why This Even Matters โ A Story First
Two friends keep identical photo albums in different cities. Every time one adds or changes a
The solution is hidden so you can try first
16 min read ยท 15 sections
4
Read the code
Fixed vs content-defined chunking: SHA-256 blocks, dedup, delta upload after an overwrite and an insert