Art of Codeartofcode
Lesson 5 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.4 What do we store?

3 min read+10 XP
blocks (object storage) key = SHA-256 of the block → bytes (encrypted at rest) files (sharded SQL) namespace_id, path, file_id, latest_version, deleted? file_versions file_id, version, block_hashes[], size, modified_by, modified_at journal namespace_id, seq, file_id, version (the change log devices sync from) namespaces a user's folder, or a shared folder (its own namespace) acl namespace_id, user_id, role

A namespace is a user's root or a shared folder; it's the shard key and the unit of sync, so everything inside one shared folder lives together.

Interviewer pushback:

  • "Why keep block hashes per version?" → Version history is then just old lists of hashes. Restoring yesterday's file is a metadata change; the blocks are already stored.

Memory code: "Blocks by hash, files as lists of hashes, a journal to sync from."