Design Dropbox / Google Drive (File Sync) — System Design

🟠 High-Level Design · Senior → 🔴 the chunking & sync deep dive

"Design Dropbox / Google Drive." A file-sync service seems mundane until you ask: when you change one line in a 2 GB video, does Dropbox re-upload the whole 2 GB? (No.) When the same file exists in a thousand accounts, does it store it a thousand times? (No.) The clever answers — chunking, deduplication, and delta sync — are what this question is really about. Let's design it.

Step 1 — Requirements

• Functional: upload/download files; sync files across a user's devices; share files; keep version history.
• Non-functional: handle huge files efficiently, sync fast (don't re-transfer unchanged data), be reliable (never lose or corrupt a file), and scale to billions of files.

Step 2 — Separate metadata from the file bytes

🟠 The foundational split: a Metadata Service (a database) tracks files, folders, versions, permissions, and which blocks compose each file; the actual file bytes live in object storage (S3). This is the same "store the URL/reference, not the blob in your DB" principle — the DB stays small and fast, the bytes scale independently.

Step 3 — Chunking (the key idea)

🔴 A file isn't stored as one big blob — it's split into small blocks/chunks (e.g. 4 MB each). A file is then just an ordered list of block references in the metadata. Why does this matter? Because it unlocks everything else:

Step 4 — Deduplication

🔴 Each block is identified by a hash of its content. Before uploading a block, the client asks "does a block with this hash already exist?" If yes, it doesn't upload it again — it just references the existing one. This deduplication is huge: the same file shared across thousands of users is stored once; even identical blocks within different files dedupe. Content-hash blocks save enormous storage and bandwidth.

Step 5 — Delta sync (only send what changed)

🔴 This is the magic users feel. When you edit a file, the client re-chunks it, compares block hashes to the previous version, and uploads only the blocks that changed. Change one line in a 2 GB file → maybe one 4 MB block changes → you upload 4 MB, not 2 GB. Downloads work the same way: a device only fetches blocks it doesn't already have. Naming "block-level delta sync via content hashes" is the standout answer.

Step 6 — How sync actually propagates

🟠 Each client watches the local folder for changes. On a change, it uploads new blocks + updated metadata to the server. The server then notifies the user's other devices (via a long-lived connection / notification channel) that "there's a new version," and those devices pull the changed blocks. So sync is: watcher → upload delta → server → notify other devices → they download delta. A queue often decouples the notification/processing from the upload.

Step 7 — Conflicts & versioning

🔴 Two devices edit the same file offline, then both sync — a conflict. Dropbox's pragmatic approach: don't silently overwrite; keep both as conflicted copies ("file (conflicted copy from Bob's laptop)") and let the user resolve. Because blocks are immutable and content-addressed, versioning is nearly free — an old version is just a different ordered list of (mostly shared) blocks, so you can restore history cheaply.

Step 8 — Architecture summary

Components: a client (watcher + chunker + hasher), a Metadata Service (files/blocks/versions/permissions, in a relational DB), a Block Storage service on object storage (deduped blocks), and a notification service to fan changes out to devices. Metadata is strongly consistent (you must agree on the current version); blocks are immutable so they replicate and cache trivially, often through a CDN for downloads.

The interview-ready walkthrough

"I'd separate metadata (a DB of files, versions, and block lists) from the bytes (blocks in object storage). Every file is chunked into small blocks identified by a content hash, which gives me deduplication (a block is stored once even across users) and delta sync (editing a huge file only re-uploads the changed blocks). Clients watch the folder, upload deltas, and the server notifies other devices to pull the changed blocks. Conflicts become conflicted copies, and immutable content-addressed blocks make versioning cheap." That leads with chunking + dedup + delta sync — the whole heart of the question."

What to read next

• Object Storage (S3) — where the deduped blocks live
• Design YouTube — another big-file storage/CDN system
• Consistency Models — strong metadata vs cheap block replication
• ← The complete System Design guide (hub)

← Design a payment system · Design Ticketmaster →