System Design Arena
Design Dropbox
Cloud file storage and sync: chunked uploads, deduplication, delta sync across devices, and sharing — the classic storage-systems interview.
Case Study
Dropbox
Same conversation, diagrams, and wrap-up you expect—now framed with clearer scaffolding and iconography.
Prompt
Design a file storage and synchronization service like Dropbox: users install a client on multiple devices, and files stay in sync across all of them.
Interview snapshot
- • Topic: Dropbox
- • Expected depth: 45 - 60 minutes
- • Focus areas: APIs, scale estimation, resilient architecture
- • Wrap-up: risk, monitoring, disaster recovery
Key takeaways
- • Upload/download files of any practical size, resumable.
- • Durability is sacred: 11 nines on content — never lose a file.
- • POST /chunks/check {hashes[]} → {missing[]} — the dedup handshake.
🎙️ Interview mode
Practice this like a real interview
Don't read the answer first. Work the framework against the bare prompt, then compare against what the interviewer expected at each step.
Scorecard
What the interviewer is evaluating
Staff-level signal
Does the candidate split metadata from content immediately, and derive dedup + delta sync + integrity from one idea — content-addressed chunks?
🧠 Staff engineer judgment
Never design sync as "upload the file again". Chunking with content addresses makes bandwidth proportional to change, not to file size — that single idea is most of the design.
Calibration
The common (bad) answer
Client uploads file → S3 Other devices poll and re-download the file
❌ Why this scores poorly: Re-uploading a 2GB file for a 1-byte edit, no dedup, no versioning, no conflict story — this is an FTP client, not Dropbox.
✓ What a strong answer adds
- Content-addressed 4MB chunks; upload only hashes the server lacks.
- Metadata service owns the namespace: file → ordered chunk list, versions.
- Append-only journal + cursor per account: offline recovery = live sync.
- Conflicted copies on concurrent edits — never silently drop a version.
- Sharing = metadata mount + ACL; content moves nowhere.
Video walkthrough
Design Dropbox or Google Drive
Hello Interview · ex-Meta staff engineer · 58 min
File chunking, sync conflicts and metadata design — the parts candidates usually skip.
Work the prompt yourself first — guided practice grades your own answer step by step. Watching someone else design it feels like progress and teaches you far less.
Interview flow
Dialogue timeline
Interviewer
Scope this for me.
Candidate
Upload/download files, sync a folder across devices with near-real-time propagation, file versioning, and shared folders. Out of scope: document editing, comments.
Interviewer
What's the defining technical idea?
Candidate
Separate metadata from content. Content is immutable chunks in blob storage; metadata — the file tree, versions, which chunks make a file — lives in a database. Sync is a metadata problem; transfer is a chunk problem.
Interviewer
How does upload work for a 2GB file?
Candidate
Client splits it into ~4MB content-addressed chunks (hash = id), asks the server which hashes it already has, uploads only the missing ones to blob storage, then commits a metadata record listing the chunk hashes in order.
Interviewer
What does content-addressing buy you?
Candidate
Global dedup — a chunk shared by a million users is stored once. Edits re-upload only changed chunks (delta sync). And integrity comes free: the hash verifies the content.
Interviewer
How do other devices find out about a change?
Candidate
Each account has a journal of metadata mutations with a cursor. Devices hold a long-poll/WebSocket to a notification service; on change they pull journal entries after their cursor and fetch missing chunks. Pull-based sync makes recovery after offline periods the same code path as live sync.
Interviewer
Two devices edit the same file while offline.
Candidate
Last-writer-wins silently loses work — unacceptable for files. On conflicting journal commits, keep both: the later commit becomes 'name (conflicted copy from device X)'. Users resolve; nothing is ever destroyed.
Interviewer
Sharing a folder with another user?
Candidate
A share is a metadata mount: the folder's subtree id appears in both accounts' namespaces with an ACL. Content chunks are already global — sharing moves no bytes, just grants metadata visibility.
Interviewer
What breaks at a billion files?
Candidate
The metadata DB. Shard the namespace by account (subtree locality), keep the journal append-only per account, and cache hot directory listings. Blob storage scales horizontally by design; metadata is where the engineering lives.
Scoping
Requirements & trade-offs
Functional Requirements
- —Upload/download files of any practical size, resumable.
- —Automatic sync across a user's devices with conflict handling.
- —Version history and restore.
- —Shared folders with permissions. Out of scope: in-app editing.
Non-Functional Requirements
- —Durability is sacred: 11 nines on content — never lose a file.
- —Sync propagation within seconds when devices are online.
- —Bandwidth-efficient: never re-upload bytes the server already has.
- —Client works offline and reconciles safely on reconnect.
Blueprint
Architecture modules
Module 1
API Endpoints
- •POST /chunks/check {hashes[]} → {missing[]} — the dedup handshake.
- •PUT /chunks/{hash} — upload one content-addressed chunk.
- •POST /commit {path, chunkHashes[], parentVersion} → new version or conflict.
- •GET /journal?cursor=… → metadata changes since cursor (long-poll).
Module 2
Back-of-the-Envelope
- •700M users × 10GB average → ~7EB logical; dedup + cold tiering cuts stored bytes several-fold.
- •4MB chunks → a 2GB file is 500 chunks; parallel upload saturates the client uplink.
- •Metadata: ~1B commits/day → append-only journal partitioned per account handles it.
- •Notification fan-out: millions of long-poll connections, tiny payloads ('cursor moved').
Module 3
System Diagram Notes
- •Client → Chunk service → Blob store (content-addressed, immutable).
- •Client → Metadata service → Namespace DB (sharded by account) + Journal.
- •Notification service pushes 'something changed'; clients pull the journal.
- •Cold chunks tier to cheaper storage; hashes make migration invisible.
Module 4
Design Playbook
- •Open with metadata/content separation — it reframes the whole problem.
- •Content-addressed chunks: one idea that yields dedup, delta sync, and integrity.
- •Journal + cursor makes offline recovery identical to live sync — say that.
- •Conflicted copies over LWW: files are the one place you never drop a write.
- •Push notifies, pull syncs — resilient to missed notifications.