01How big can a file get? That number drives the whole upload design.
Users upload and download from any device, with files up to 50 GB — which forces chunked, resumable transfers from day one.
Free full guide
Dropbox
Design Dropbox — a cloud file storage and synchronization service where users upload large files and keep them in sync across devices and shared folders.
00
Practice checkpoints
The interview rhythm stays compact, so the page can spend attention on the actual design decisions.
- 01Clarify scope
- 02Requirements + scale
- 03API + data model
- 04Draw architecture
- 05Deep dive
- 06Trade-off decision
01
Requirements that shape the design
Do not only state requirements. Ask for them. Each card pairs the design constraint with a clarification question you can say out loud before drawing the architecture.
Functional requirements
02Is sync automatic, and what happens to offline edits?
Files sync automatically across all devices; edits made offline reconcile on reconnect — the server copy is the source of truth.
03What does sharing mean — a copy, or the same file?
Sharing grants access to the same file: recipients see it in their own view, and updates propagate to everyone with access.
04Are folders, moves, and renames file operations?
No - folders are metadata: move and rename are metadata-only operations that never touch stored blocks, so they are instant at any file size.
05Does sharing carry permissions - view-only vs edit?
Yes: share grants carry a role (viewer/editor) enforced at the metadata service, and presigned URLs are scoped to the role that requested them.
06Do deletes sync, and can a user recover a deleted file?
Deletes propagate as tombstones like any edit, with a trash window before blocks are reclaimed - sync-a-mistake needs an undo story.
Out of scopeIn-place collaborative editing (that is the collaborative document-editing question) · Preview and rendering without download · Version history UI (the data model keeps latest_version, but browsing history is out)
Non-functional requirements
01When the network partitions, what must keep working?
Availability over consistency: a stale file list for a few seconds is fine; failing an upload is not.
02What happens when a 50 GB upload dies at 49 GB?
It resumes from the last verified chunk — never restarts. Chunk status is tracked server-side, so any device can continue the upload.
03How do we know a file was not corrupted in transit?
Every chunk and the whole file carry SHA-256 fingerprints; a chunk is only marked uploaded after the storage layer confirms the bytes.
04Two users upload the same 2 GB video — do we store it twice?
No: identical fingerprints mean identical content — the metadata points both users at the same stored blocks.
05How fresh does cross-device sync need to be?
Seconds: online devices get pushed change notifications, with periodic polling as the safety net.
Keep asking — the interview is a conversation
Real interviews probe far more than a tidy list. These are the scope questions that separate candidates who interrogate the problem from those who recite it.
- What is the max file size — megabytes or tens of gigabytes?
- Is collaborative in-place editing in scope, or files-as-blobs only?
- When two devices edit the same file offline, what should the user end up seeing?
- Do we need version history, or just the latest version?
- Should identical content uploaded by different users be stored once?
02
Numbers that force architecture decisions
Treat every estimate as a pressure that justifies a component: cache, queue, partition, replica, worker pool, or fallback path.
Chunks per big file
50 GB file ÷ 5 MB chunks50,000 MB ÷ 5 MB = 10,000 chunks
Ten thousand independent, parallel, individually-resumable uploads — this is why one giant POST can never work.
Resume cost after failure
Upload dies at 98%retry = the remaining ~200 chunks, not 10,000
Chunk-status tracking turns a catastrophic restart into a 2% top-up.
Dedup win
Same file uploaded by N users, fingerprint-matchedstorage cost = 1 copy + N metadata rows
Content-addressed storage makes the second and every later upload nearly free.
Edit one byte
Fixed-size chunking vs content-defined chunking (CDC)fixed: a 1-byte insert shifts every boundary → nearly all chunks re-upload · CDC: only the touched chunks
CDC (rolling hash) is what makes delta sync cheap for edited files.
Presigned URL window
URLs valid ~5 minutes, scoped to one chunkleak window = minutes · blast radius = one chunk
Short-lived, narrow-scope URLs are the security story for client-direct upload.
Decision example
The numbers
A 50 GB file is ten thousand 5 MB chunks. At that size the interesting problems are not storage — they are resume, dedup, and what happens when two devices edit the same file.
My choice
I would have clients chunk and fingerprint files locally, then upload chunks in parallel straight to blob storage using short-lived presigned URLs — the API brokers metadata only, and verifies chunk ETags before marking them done. Sync is a pushed notification plus a changes-since cursor each device reconciles against. For conflicts: last write wins for the main copy, and the losing edit is kept as a conflict copy next to it — the user loses nothing and resolves it themselves.
Avoid
What I would NOT do: route file bytes through my API servers — they become a bandwidth bottleneck and an attack surface for zero benefit. And I would not silently drop the losing edit in a conflict: pure last-write-wins is fine for a file LIST, but for file CONTENT, quietly discarding someone’s afternoon of work is how you lose customers.
Change if
If in-place collaborative editing enters scope, blob-level sync is the wrong tool entirely — that becomes operational transforms or CRDTs over document structure: a different design, and a different interview question.
03
Architecture path
Draw the write path and the read path as separate lanes — they carry different traffic and justify different components.
File bytes flow client → blob storage directly (presigned URLs); only metadata passes through the API. The notification service tells other devices to pull the changes cursor.
Dedup check first — a known fingerprint completes without uploading a byte. Chunks upload in parallel; the file flips to complete only after every chunk’s ETag verifies.
Push is the doorbell, the changes cursor is the truth: even a missed notification self-heals on the next poll.
04
API and data model
Before optimizing, make the contract inspectable: endpoints, entities, ownership, retries, and state.
POST/files/presigned-url
req{ name, size, fingerprint, chunk_fingerprints[] }
res200 { file_id, presigned_urls[] } · 200 { deduplicated: true } when the fingerprint already exists
The client uploads chunks straight to blob storage with these URLs — file bytes never pass through the API servers.
PATCH/files/{file_id}/chunks
req{ chunk_id, etag }
res200 chunk status
Trust but verify: the server accepts the client’s progress report, then confirms the ETag against blob storage before counting the chunk as uploaded.
GET/files/{file_id}/presigned-url
res200 { url } (CDN-signed, short expiry)
Downloads come from the CDN edge; short-lived signed URLs keep share links from becoming permanent public URLs.
GET/files/changes?since={cursor}
res200 [{ file_id, change, version }]
The sync backbone: push notifies “something changed”; this endpoint is the truth a device reconciles against.
Core entities
FileMetadatafile_id (PK) · name · size · fingerprint (SHA-256) · latest_version · status · chunks[] {id, fingerprint, status}
file_id (identity) is deliberately separate from fingerprint (content) — a rename changes neither the content nor the stored blocks.
SharedFilesuser_id (partition key) · file_id (sort key)
One row per user per shared file: "what can this user see" is a single-partition query.
Devicedevice_id (PK) · user_id · last_synced_at
Sync state is per device — each device pulls changes since its own cursor.
05
Deep dive directions
Pick one lane for the final third of the interview. Each lane gives you the topic, the interviewer question it should answer, and the failure mode to avoid.
FocusThe 50 GB upload
AskWalk the upload end to end: chunking, parallelism, what the server tracks, and what happens when it dies at 98%.
AvoidOne multipart POST and a retry-from-zero — at this size, resume IS the feature.
FocusSame file, two uploaders
AskTwo users upload an identical 2 GB video. What actually gets stored, and how does the system know?
AvoidDeduping by filename or size — only content fingerprints (SHA-256) define identity.
FocusTwo devices edit offline
AskLaptop and phone both edited the same file offline. Both come online. What does the user end up with?
AvoidSilently keeping only the last write — the losing edit must survive as a conflict copy.
FocusWhy clients upload straight to blob storage
AskWhat breaks if file bytes flow through the API servers, and what exactly do presigned URLs protect?
AvoidLong-lived or file-wide presigned URLs — minutes of validity, one chunk of scope.
FocusEdit one byte, sync one chunk
AskA user inserts one byte at the top of a big file. How much re-uploads under fixed-size chunking, and how does content-defined chunking fix it?
AvoidAssuming fixed chunking is fine for edited files — boundary shift invalidates every following chunk.
Ready to practice?
Talk through Dropbox out loud and get AI scoring on the explanation.