Keeping files in sync across devices
Design a Dropbox-Style File Sync Service, from a blank page
This is how the interview actually runs: one prompt, and you decide what to cover and in what order. Write each section, then compare it with a reference design and see what you left out.
A 45-minute round. You drive; nothing prompts you.
The prompt
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 the interviewer would tell you if you asked
- 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.
01
about 5 minWhat does the system have to do, and how well? List the functional requirements, then the non-functional ones (latency, availability, consistency, scale), and the questions you would ask the interviewer.
02
about 5 minTurn the volumes into the numbers that drive the design: requests per second at peak, storage, bandwidth, and anything else that decides whether one machine is enough.
03
about 10 minName the components and what each one is responsible for. Then trace the main request through them, and say where the durable state lives.
04
about 15 minPick the hardest decisions in this design and make them: what you chose, what you rejected, and which constraint decided it.
05
about 10 minWhat breaks? Walk through crashes, duplicates, slow dependencies and overload, and what the design does in each. Then: what changes at ten times the load, or with a new requirement?
Write something in at least 3 sections first. Gaps are fine; the comparison shows what they cost.