Design Dropbox

Problem statement

Design a cross-platform file synchronization and cloud storage platform that monitors local folders for changes, splits files into content-defined blocks, syncs only changed blocks to the cloud, propagates updates across all of a user's devices, maintains version history, resolves conflicts when multiple devices edit the same file simultaneously, and supports sharing through public links and permissioned folders.

This is not a simple file-upload problem. A user may have 200,000 files totalling 500 GB across a laptop, a desktop, and a phone. They edit a 120 MB PowerPoint on the laptop while offline, a colleague edits the same file through a shared folder on their desktop, and both devices reconnect within seconds of each other. The platform must detect the conflict, preserve both versions, and notify both users — without losing a single byte. Meanwhile, a third user opens a shared link to a 2 GB video and expects streaming playback within 500 ms.

Why the problem is distinctive

A photo-sharing service can treat each upload as an independent object. A file-sync platform cannot. The same file is mutated in place, renamed, moved between folders, partially edited, and accessed from multiple devices concurrently. The sync engine must track a Merkle tree of content hashes per folder, detect which blocks changed since the last sync, upload only those blocks, and apply remote changes locally — all while the user continues working. The local client is a stateful daemon, not a stateless browser.

The attached brief requires local file watchers and cloud-based sync, conflict resolution, version history and restore, sharing features with permissions, scalability for large user bases, low-latency incremental sync, reliability with no data loss, and selective sync for large folders.

Public operating baseline versus design assumptions

Dropbox reported more than 700 million registered users and approximately 17.8 million paying subscribers as of fiscal year 2022. The company publicly stated it stored over 600 billion files and migrated from Amazon S3 to its own "Magic Pocket" infrastructure, saving an estimated $75 million over two years. These are cited public figures providing context for the problem's scale.

For capacity planning, this answer explicitly assumes a mature platform with 500 million registered users, 20 million paying subscribers, 40 million monthly active users, and 8 million daily active sync sessions. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold — not a claim about any company's private architecture.

The four architectural planes

1. Sync plane: local file watcher, content-defined chunking, delta detection, block upload/download, conflict resolution, and the sync state machine.
2. Storage plane: content-addressed block store, deduplication, tiered storage, version history, and data durability.
3. Metadata plane: namespace tree, file attributes, sharing permissions, folder subscriptions, and search index.
4. Collaboration plane: shared links, shared folders, access control, notifications, and real-time editing for documents.

A strong interview answer keeps these planes separate. It allows the collaboration plane to degrade without breaking the sync plane, and it permits the storage plane to tier cold blocks without affecting the metadata plane's consistency guarantees.