Art of Codeartofcode
Lesson 15 of 16

39. Design File Storage and Sync (Google Drive / Dropbox)

1
The interview prompt
2
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 yourself
14
Variations to practise
15
Sources
16
Code lab
39. Design File Storage and Sync (Google Drive / Dropbox)

Sources

3 min read+10 XP

Source notes

  • Dropbox splitting files into chunks of up to 4 MB hashed with SHA-256, and the de-duplication side channel: Martin Mulazzani et al., "Dark Clouds on the Horizon: Using Cloud Storage as Attack Vector and Online Slack Space", USENIX Security 2011. Checked 2026-10-08.
  • Amazon S3 multipart upload limits (parts from 5 MiB to 5 GiB, at most 10,000 parts): Amazon S3 User Guide, "Amazon S3 multipart upload limits". Checked 2026-10-08.
  • Content-defined chunking with rolling hashes: Athicha Muthitacharoen, Benjie Chen and David Mazières, "A Low-bandwidth Network File System" (LBFS), SOSP 2001.
  • Dropbox metadata on sharded MySQL: Dropbox engineering blog posts on its metadata storage.
  • All user, storage and change-rate numbers are interview assumptions agreed in Step 1, not figures for any real service. Arithmetic computed 2026-10-08.
  • Fixed vs content-defined chunking, content-addressed de-duplication, versioned commits with conflicted copies, journal cursors and presigned URLs: tested 2026-10-08 (code/ch39_file_sync.py, all checks pass).