18
Dropbox / Google Drive
Chunking, dedup, sync, conflict resolution.SavedSaved on this device — Saved on this device
01Clarifications
What would you ask before drawing a single box?
Ambiguity you would resolve with the interviewer: scope, scale, who uses it, what counts as done.
AI staff engineer
Enter to send · Shift+Enter for a new line
About Dropbox / Google Drive
Chunking, dedup, sync, conflict resolution.
- Difficulty
- advanced
- Time
- about 55 minutes
- Stages
- 10
- Topic
- Object Storage, File Sync & Media Delivery
How this problem is worked
Ten stages, from the questions you would ask an interviewer to the trade-offs you would defend. Each asks one question, and the simulator runs the architecture you draw against the requirements you wrote.
- 01ClarificationsWhat would you ask before drawing a single box?
- 02Functional reqsWhat must this system actually do?
- 03Non-functionalWhat must it promise about speed, uptime and correctness?
- 04Capacity estimationHow much load and data does this have to hold?
- 05API designWhat does the outside world call, and what comes back?
- 06Data modelWhat gets stored, and what is it looked up by?
- 07Use-case breakdownHow does each requirement actually get served?
- 08High-level designWhich components handle a request, and in what order?
- 09Deep divesWhich part breaks first, and what do you do about it?
- 10Trade-offsWhat did this design cost, and what breaks at 10×?
Primary sources for this problem
- Dropbox — Inside the Magic Pocket
- Dropbox — Streaming File Synchronization (journal + cursors)
- Dropbox — Rewriting the heart of our Sync Engine (Nucleus)
- Dropbox — Panda: petabyte-scale transactional KV over sharded MySQL
- Dropbox — Reintroducing Edgestore
Build the primitives this design leans on
Each one is an animated curriculum that constructs the system from scratch.
- Build Build a Bitcask-style KV storeThe simplest possible KV store that still works: an append-only log on disk + an in-memory hash index. Build it from first principles and feel which trade-offs every later store inherits.
- Build Build an LSM-tree storage engine (LevelDB / RocksDB style)The simplest possible storage engine that gives you BOTH ordered reads AND more keys than fit in RAM, by accepting a deal: write to RAM at memory speed, log to disk for safety, then merge sorted files in the background forever.
More in Object Storage, File Sync & Media Delivery
Durable bytes at rest and bytes in flight: an S3-style object store, a Dropbox-style sync client, and adaptive video streaming.
- Build Build an S3-style distributed object storeEleven nines of durability over disks that fail weekly. Build the object store from first principles — flat keyspace, immutable objects, erasure coding instead of replication, eventual consistency turned strong, multipart upload, lifecycle and tiering — and feel why every modern data lake sits on top of something shaped exactly like this.
- YouTube / Netflix StreamingABR, CDN, transcoding, hot/cold — the egress, fan-out, and popularity Pareto.
Browse the full problem catalog, or see what the simulator does and does not model.