Art of Codeartofcode
Lesson 12 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)

39.11 What would you say in the last five minutes?

3 min read+10 XP

Step 6: Wrap-up (5 minutes)

  • Bottlenecks: upload bandwidth (direct-to-storage, multipart, only missing blocks) and metadata writes (sharded by namespace).
  • Single points of failure: none central: block storage is replicated across zones; metadata shards have replicas and failover; notifiers are stateless.
  • Correctness: content hashes verify every block; compare-and-set prevents silent overwrites; commits happen only when all blocks exist.
  • Cost: de-duplication, compression, and moving old versions and cold files to cheaper storage tiers (Chapter 11).
  • Next with more time: selective sync (only some folders on the laptop), LAN sync between devices in the same office, previews and thumbnails, full-text search over documents (Chapter 19), and ransomware detection (sudden mass changes → offer a restore).

Memory code: "Bytes in blocks, truth in metadata, conflicts kept, uploads direct."