Design Dropbox Sync

Three logical APIs: metadata (file tree + versions), blocks (raw byte I/O), and notify (push changes to clients). Clients talk HTTPS for metadata + blocks and hold a long-poll / WebSocket for notify.

Three tiers: block storage (content-addressable; SHA-256 keyed), metadata service (sharded OLTP), and the client sync engine (watches filesystem + talks to server). Notify service is a thin pub/sub on top. Dropbox famously moved off AWS S3 onto their own block storage system ("Magic Pocket") in 2016 for cost.

When a user saves a 100 MB photo, the sync loop does NOT upload 100 MB. Here's the exact sequence:

1. FS watcher fires. OS-level file-system event (inotify on Linux, FSEvents on macOS, ReadDirectoryChanges on Windows) tells the client "foo.jpg changed."
2. Client chunks the file. Split into 4 MB blocks. Compute SHA-256 of each block. Result: 25 hashes for our 100 MB photo.
3. Query /blocks/check with 25 hashes. Server looks them up in the block-metadata DB (refcount > 0 = already stored somewhere). Returns which are missing. For a small edit to an existing photo, only the changed blocks are missing — often just 1–2.
4. Upload only missing blocks. Concurrent PUT /blocks/{hash}. Server verifies bytes-hash = URL-hash, writes into Magic Pocket (durably replicated).
5. Commit metadata. POST /metadata/commit with new block list, parent_rev. Server CAS on parent_rev — if another device changed meanwhile, returns a conflict for the client to resolve.
6. Notify other devices. Metadata write emits event; Notify service pushes "something changed" to subscribed clients. They call /metadata/delta to pull new metadata and (if they have the file open) fetch needed blocks.

Cross-user dedup. The content-addressable store keys blocks by their SHA-256 hash. If user A uploads a block with hash X, and later user B's client asks "do you have X?", the answer is yes — no upload needed. Storage cost drops ~30% from cross-user dedup on typical mixed workloads (much higher for shared software installers, documents templates, stock photos).

sequenceDiagram
    participant C as Client
    participant BL as Block svc
    participant ST as Block storage
    participant M as Metadata svc
    participant N as Notify

    C->>C: chunk file → [h1..h25]
    C->>BL: POST /blocks/check [h1..h25]
    BL-->>C: missing: [h7, h19]
    par concurrent uploads
        C->>BL: PUT /blocks/h7
        BL->>ST: write (replicated)
        ST-->>BL: ok
    and
        C->>BL: PUT /blocks/h19
        BL->>ST: write (replicated)
        ST-->>BL: ok
    end
    C->>M: POST /metadata/commit {blocks, parent_rev}
    alt parent_rev matches
        M-->>C: rev=42
        M->>N: FileChanged event
        N-->>C: push to other devices
    else stale parent_rev
        M-->>C: 409 conflict + server state
        Note over C: run conflict resolver
    end
          

Conflict resolution. Two devices edit the same file offline, both come online and commit. Dropbox's choice: both versions are preserved. The second commit creates foo.txt and foo (user's conflicted copy).txt. Simple, predictable, survives years of production use. They explicitly chose not to do OT / CRDT merging — file systems don't have semantic awareness of the content.

Delta sync for big files. For large files (> 100 MB) changed in small ways (e.g., a 2 GB video with re-edited metadata), block-level chunking naturally gives delta — only the block(s) containing the change are uploaded. For rolling changes (inserts in the middle of a file shift all subsequent block boundaries), Dropbox uses rolling hash chunking (Rabin fingerprint) so chunk boundaries follow content, not fixed offsets. A rename or middle-insert only shifts 1–2 blocks, not the whole rest of the file.

• Fixed-size vs rolling-hash chunks. Fixed-size (4 MB) is simple and fast. Rolling hash (Rabin fingerprint) gives better delta ratios on files with mid-content inserts but costs more CPU + breaks cross-user dedup slightly (same logical content can hash differently). Dropbox uses hybrid — fixed by default, rolling for media.
• Block store separate from metadata store. Metadata (tree structure, versions, ACLs) is transactional — OLTP on MySQL. Blocks are immutable byte bags — object storage on Magic Pocket. Conflating them would put transactional constraints on byte-addressed storage = slow.
• Save both on conflict vs merge. Save-both is the right call for generic files. Merging requires understanding file format (text, docx, images) — out of scope for a sync engine. Google Docs has per-character merge because it owns the editor too.
• Magic Pocket vs S3. Dropbox moved off S3 in 2016 because at their volume, running their own storage (with custom erasure coding) was cheaper. The "build vs buy" crossover is specific to storage-heavy businesses.
• Long-poll vs WebSocket for notify. Both work. Long-poll simpler, survives more firewalls, wastes a little compute at the server. WebSocket holds state but more efficient. Dropbox uses long-poll historically; modern clients shifted toward WS.

1. Lead with chunking + content-addressable storage. This is THE answer to "how do you make this efficient?" Most candidates miss this and just "upload the file to S3."
2. Separate metadata from blocks. Metadata is transactional (needs DB); blocks are immutable byte bags (object store). Don't conflate them.
3. Conflict resolution is "save both." Not OT/CRDT. Name this explicitly — it shows you understand the scope of a sync engine vs a collab editor.
4. Delta sync via chunk hashes. 99% of candidates think "rsync-style diff" — the correct Dropbox answer is "chunked CAS, query missing hashes, upload only those."
5. Offline-first is the sync loop's existence. If you don't have a client-side SQLite holding pending ops + a reconcile step, your design assumes online-always.