Design Dropbox / Google Drive (File Storage & Sync)

Dropbox looks like "upload files, download files" — a glorified FTP server. That framing fails the interview. The real problem is sync: a user edits a 2 GB video on their laptop, and thirty seconds later the updated file is on their desktop, their phone, and their teammate's machine — without re-uploading 2 GB. That gap between the naive design and the real one is exactly what interviewers are probing.

This question tests three things at once: large binary data handling (you cannot stuff files in a database), bandwidth-efficient protocols (chunking, hashing, delta sync), and multi-device consistency (what happens when two devices edit the same file offline?). Junior candidates are expected to separate metadata from blob storage; senior candidates are expected to design the chunking pipeline and defend a conflict-resolution strategy.

Functional requirements

• Upload and download files from any device.
• Automatic sync: a change on one device propagates to all of the user's devices.
• Offline edits: users can modify files without connectivity; changes sync on reconnect.
• File versioning: restore a previous version of a file.
• (Clarify) Sharing files/folders with other users — call it out, then de-scope it.
• (Clarify) Max file size — assume up to a few GB; it justifies chunking.

Non-functional requirements

• Durability above all. Losing a user's only copy of their thesis is an extinction-level event for this product. Aim for eleven nines.
• Eventual consistency across devices is acceptable — a few seconds of sync lag is fine; losing an edit is not.
• Bandwidth efficiency. Users edit large files constantly; re-uploading whole files would destroy mobile data plans and your egress bill.
• High availability for the sync path; reads and writes are roughly balanced (unlike TinyURL, this is not read-dominated).

Assume a mid-size Dropbox:

• Users: 50M registered, 10M daily active.
• Storage: 50M users × 10 GB average = 500 PB raw. This single number reshapes the design — you are not building a database, you are building on top of an object store.
• Deduplication saves real money: identical chunks (shared files, common installers, re-uploads, small edits to big files) mean typical dedupe ratios of 25–50%. At 500 PB, a 30% saving is 150 PB — tens of millions of dollars a year. Dedupe is not an optimization; it is the business model.
• Upload traffic: 10M DAU × 2 file edits/day ≈ 20M uploads/day ≈ ~230 uploads/sec (peak ~1,000/sec). With delta sync, each "upload" averages a few chunks, not a whole file.
• Metadata: 50M users × ~1,000 files × ~1 KB of metadata ≈ ~50 TB — big, but a sharded relational database handles it. Metadata QPS (sync checks, listing folders) dwarfs file traffic: budget ~10× the upload rate.

The upload flow is a two-phase conversation: the client tells the server which chunk hashes it has, the server replies with which ones it is missing, and the client uploads only those. That negotiation is the API's whole personality.

Note two deliberate choices: chunks go directly to blob storage via pre-signed URLs (your app servers never proxy petabytes), and the commit carries a baseVersion so the server can detect concurrent edits (Step 5).

The metadata schema is three tables — files, versions, and chunks:

This is where the interview is won or lost. Chunking solves four problems with one mechanism:

1. Resumable uploads — a dropped connection at 95% of a 2 GB file loses one chunk, not the whole transfer.
2. Delta sync — edit page 3 of a document and only the chunks covering page 3 change; the rest hash identically and never leave the device.
3. Deduplication — chunks are identified by their SHA-256 content hash. If any user anywhere has already uploaded a chunk with that hash, it is never stored (or transferred) again.
4. Parallelism — chunks upload and download over concurrent connections, saturating the pipe.

Dropbox uses 4 MB chunks. The size is a trade-off: smaller chunks dedupe better and localize edits more tightly, but every chunk costs a metadata row and a request — a 2 GB file at 64 KB chunks is 32,768 rows. 4 MB keeps that same file at 512 chunks while still isolating most edits.

The subtle question is where the chunk boundaries go:

A strong answer: start with fixed-size 4 MB chunks — it captures most of the win for append-heavy and in-place edits — then name the boundary-shift problem and offer content-defined chunking as the fix for insert-heavy workloads. Knowing why rsync and modern backup tools use rolling hashes is a senior signal; deriving Rabin fingerprints on the whiteboard is not required.

One caveat worth volunteering: cross-user dedupe has a privacy wrinkle. If the server admits "I already have that chunk," an attacker can probe whether anyone has stored a known file. Per-user dedupe or convergent encryption are the standard mitigations — one sentence on this earns real credit.

The sync loop has four players:

• Client watcher — a daemon on each device watches the sync folder (inotify/FSEvents), chunks and hashes changed files, and talks to the API from Step 3. It keeps a local database of known hashes so offline edits queue up cleanly.
• Metadata service — owns the metadata DB, which is the single source of truth. A file version does not exist until its commit lands here; blob storage is just a bag of chunks.
• Notification service — when a commit lands, it pushes an invalidation ("file X is now version 7") to the user's other devices. Use long polling or WebSockets: with millions of mostly-idle devices, having clients poll every few seconds would melt the metadata tier, and long polling gets near-instant sync at a fraction of the request volume. The notification is deliberately tiny — just "something changed" — and the device then fetches the new chunk list and downloads only the chunks it lacks.
• Blob storage — stores chunks keyed by hash; covered in Step 6.

Conflicts. Two devices edit budget.xlsx offline, then both reconnect. Each commit carries the baseVersion it was edited against — the server accepts the first commit (version 6 → 7) and rejects the second because its base (6) is no longer current. Now what?

Putting it together:

• Blob storage (S3 or equivalent) holds every chunk, keyed by content hash. It gives you eleven-nines durability, effectively infinite capacity, and pre-signed URLs so app servers stay out of the data path. Interestingly, Dropbox famously ran on S3 for years, built its own storage layer (Magic Pocket) at extreme scale, and that is a cost-at-scale story worth a sentence — not a design you should propose.
• Cold storage tiering. Most chunks are written once and never read again — old versions, forgotten files. Lifecycle rules move chunks untouched for 90+ days to infrequent-access or Glacier tiers, cutting storage cost 2–5× on the long tail. At 500 PB, tiering is worth more than most performance optimizations.
• Metadata DB: sharded relational (e.g., MySQL/Postgres sharded by owner_id so one user's sync touches one shard), with the version tables from Step 3. Transactions matter here — a commit must atomically bump current_version and insert the chunk rows.
• Garbage collection: when versions are pruned, decrement ref_count on their chunks; a background job deletes chunks that hit zero. Getting refcounting right (races between upload and GC) is a classic follow-up.

One design decision deserves an explicit trade-off — who does the chunking?

1. Storing files in the database. BLOBs in Postgres at 500 PB is an instant red flag. Metadata in the DB, bytes in object storage — draw that line early.
2. Uploading whole files on every edit. If your design re-transfers 2 GB because one paragraph changed, you have missed the point of the question. Chunking and delta sync are the question.
3. No conflict story. "The last write wins" for user files means silently deleting someone's work. Interviewers push on offline edits precisely to see if you have thought about this.
4. Proxying file bytes through app servers. Pre-signed URLs exist so your stateless tier never touches chunk data. Streaming petabytes through app servers is an expensive architectural mistake.
5. Polling for changes. Ten million devices polling every five seconds is 2M QPS of "anything new?" — long polling or WebSockets cuts that by orders of magnitude.
6. Ignoring durability. Never saying the words "replication" or "durability" on a question about storing people's only copy of their data is disqualifying at senior level.