Dropbox File Storage – System Design Interview Preparation

Practice designing a file storage and sync service like Dropbox. Cover file chunking, deduplication, sync protocols, and conflict resolution.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Dropbox design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Dropbox is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Syncing a mutable file across devices without re-uploading it, which makes chunking and delta sync the design rather than storage.

Scale to establish before drawing anything

A 100 MB file edited in one place should cost a few MB to sync, not 100 MB.
Several devices per user, any of which may be offline and edit the same file.
Deduplication across users is substantial - the same file exists in many accounts.

Core components

Chunker – Splits files into content-defined chunks, usually around 4 MB, hashed individually.
Metadata service – File tree, versions and the chunk list per version. Small, strongly consistent, and the source of truth.
Block storage – Chunks keyed by hash. Identical chunks are stored once across all users.
Sync service – Diffs local and remote chunk lists and transfers only what is missing.
Notification service – Long-polling or push so clients learn about changes without polling the metadata store.

Trade-offs to defend

Content-defined versus fixed-size chunking – Fixed boundaries mean inserting a byte at the start re-chunks the whole file. Content-defined boundaries survive insertions, which is the point.
Metadata consistency versus block eventual consistency – The file tree must be strongly consistent; blocks can replicate lazily because they are immutable and content-addressed.
Conflict handling – Two offline edits to one file cannot be merged safely in general. Keeping both as a conflicted copy is the honest answer; silent last-write-wins loses data.

Follow-up questions to expect

A byte is inserted at the start of a 1 GB file. How much is uploaded, and why?
Two devices edit the same file offline and both come online. What does the user see?
A user shares a folder with 50 people. How does a change reach all of them?