39. Design File Storage and Sync (Google Drive / Dropbox)
1
The interview prompt2
39.1 What do you ask first?3
39.2 How big is this, really?4
39.3 What are the doors?5
39.4 What do we store?6
39.5 What does the whole system look like?7
39.6 How does chunking work?8
39.7 How does de-duplication work?9
39.8 How do sync and conflicts work?10
39.9 How is the metadata database designed?11
39.10 How do presigned uploads work?12
39.11 What would you say in the last five minutes?13
Score yourself14
Variations to practise15
Sources16
Code lab39. Design File Storage and Sync (Google Drive / Dropbox)
39.3 What are the doors?
3 min read+10 XP
Step 3: API and data model (10 minutes)
POST /v1/files/commit/check { "path": "/Reading list.txt", "block_hashes": ["9f2…", "a71…", ...] }
returns: { "missing": ["a71…"], "upload_urls": { "a71…": "https://blocks…?expires=…&sig=…" } }
PUT <presigned URL> (client uploads each missing block directly to storage)
POST /v1/files/commit { "path": "/Reading list.txt", "base_version": 1,
"block_hashes": [...], "size": 1048576 }
returns: 200 { "version": 2 } | 409 { "current_version": 2 } (someone else changed it)
GET /v1/changes?cursor=… → { "entries": [ {path, version, block_hashes, deleted}, ... ], "cursor": "…" }
GET /v1/changes/wait?cursor=… (long-poll: returns when something changes)
POST /v1/shares { "path": "/Book club", "with": "ravi@…", "role": "editor" }