dropbox

Starting Point

Starting point: The simplest file storage service. Users upload entire files to a single server, which stores the raw file on disk and records the filename + path in a database.

How it works:

1. Client sends the entire file to the File Server over HTTP.
2. File Server writes the raw bytes to local disk.
3. File Server records the filename and path in the database.

Three critical flaws:

The most fundamental flaw is treating files as atomic blobs. We need to break them apart.

Solving Resumability and Deduplication

Problem being solved: Large files can't be uploaded atomically — network interruptions, storage waste from duplicates, and inability to parallelize uploads.

Solution: Divide every file into fixed-size 4MB blocks before upload. Each block is hashed with SHA-256 to produce a unique fingerprint. The hash serves as the block's identity — its address in the storage system.

How it works:

1. Client splits the file into 4MB blocks.
2. Client computes SHA-256 hash for each block.
3. Client asks the Block Server: "Do you already have blocks with these hashes?"
4. Block Server responds with a list of missing hashes (blocks it doesn't have).
5. Client uploads only the missing blocks — skipping duplicates entirely.
6. Once all blocks are uploaded, client sends metadata (filename, path, ordered block list) to the Metadata Server.

Why 4MB blocks?

Dropbox chose 4MB as the production block size based on empirical testing.

What we've solved:

• ✅ Resumability: If upload fails at block 5 of 10, resume from block 5.
• ✅ Deduplication: Identical blocks (across all users) are stored once. Dropbox reports ~60% dedup rate.
• ✅ Parallelism: Upload multiple blocks concurrently for faster throughput.

What's still broken:

• ❌ No cross-device sync: If I upload a file on my laptop, my phone doesn't know about it.
• ❌ No versioning: Overwriting a file destroys the old version.
• ❌ Single Block Server: All blocks in one place — no redundancy.

Solving Sync and Versioning

Problem being solved: After a file is uploaded from Device D1, other devices (D2, D3) don't know the file exists. We need a way to (a) track what files exist and what blocks compose them, and (b) notify other devices when changes happen.

Solution: Introduce two new services:

• Metadata Server — stores the file tree (names, paths, block lists, versions) in an RDBMS.
• Notification Service — maintains long-poll connections with all clients and notifies them when changes occur.

Write path (uploading a file from D1):

1. D1 splits the file into 4MB blocks, computes hashes, and uploads missing blocks to the Block Server.
2. D1 sends file metadata (filename, path, ordered block list) to the Metadata Server.
3. Metadata Server writes to the Metadata DB (PostgreSQL) and notifies the Notification Service: "file X changed in namespace Y."
4. Notification Service closes the open long-poll connections for all devices in namespace Y. This is the signal: "something changed, go check."

Read path (syncing to D2):
5. D2's long-poll connection returns. D2 queries the Metadata Server: "What changed since my last sync? (journal ID = 40)."
6. Metadata Server returns the list of changed files with their block hashes.
7. D2 checks which blocks it already has locally. For missing blocks, it downloads from the Block Server.
8. D2 reconstructs the file from blocks and saves it locally.

What we've solved:

• ✅ Cross-device sync: Notification Service ensures all devices learn about changes.
• ✅ Metadata consistency: PostgreSQL gives ACID guarantees for the file tree.

What's still broken:

• ❌ No versioning: Saving metadata overwrites the previous entry. No history, no rollback.
• ❌ Offline devices: If D2 was offline during the notification, what happens when it comes back?
• ❌ Block Server scalability: Single Block Server + S3 is a bottleneck at 600PB scale.

Solving Versioning and Offline Devices

Problem being solved: (1) No version history — overwriting a file loses the old version. (2) Offline devices miss notifications — when D2 comes online, how does it know what changed?

Solution: Add a Journal table — an append-only log of every change to every file. Each entry records what changed, when, and which blocks were affected. Devices track their last-seen journal ID and sync by asking "what happened after journal ID X?"

How journaling solves both problems:

Versioning:

• Every file modification creates a new journal entry (change type, affected blocks, previous block list for rollback).
• The file_metadata table always points to the latest_journal_id.
• To restore version N: look up journal entry N → get previous_block_list → reconstruct.
• Users can view version history: SELECT * FROM journal WHERE file_id = ? ORDER BY journal_id DESC.

Offline device sync:

• Each device remembers the last_journal_id it processed.
• When D2 comes online: query SELECT * FROM journal WHERE journal_id > {last_seen} AND namespace_id IN (user's namespaces) ORDER BY journal_id ASC.
• D2 replays the journal entries in order, downloading any new blocks it needs.
• This is exactly the same mechanism as an event-sourcing pattern.

What we've solved:

• ✅ Full version history: Every change is an immutable journal entry.
• ✅ Offline sync: Devices catch up by replaying the journal from their last checkpoint.
• ✅ Conflict detection: If D1 and D2 both modify the same file offline, their journal entries will have different previous_block_list values, signaling a conflict.

What's still remaining:

• ❌ Block storage scalability: We need distributed blob storage, not a single server.
• ❌ Metadata caching: At 23K QPS, PostgreSQL alone will struggle.

Final Design

The final architecture adds distributed block storage, metadata caching, and completes the system with all components needed for production-grade Dropbox.

NFR Scorecard — All Requirements Met

Deep Dive #1

Our 4MB fixed-block chunking has a subtle flaw: inserting a single byte at position 0 shifts all subsequent block boundaries. Every block after the insertion point gets a new hash, even though the actual content barely changed. A 1-byte edit to a 1GB file would re-upload 250 blocks (1GB) instead of 1.

Fixed-size chunking failure example:

Original:   [  Block 0  ][  Block 1  ][  Block 2  ][  Block 3  ]
Insert 1 byte at start:
After:      [ Block 0'  ][ Block 1'  ][ Block 2'  ][ Block 3'  ]
              ↑ shifted   ↑ shifted    ↑ shifted    ↑ shifted
All blocks changed! All re-uploaded. (Bad)

Solution: Content-Defined Chunking (CDC) with rolling hash.

Instead of splitting at fixed byte offsets (every 4MB), split at positions determined by the content itself. Use a rolling hash (Rabin fingerprint) that slides a window over the file bytes. When the hash hits a specific pattern (e.g., lowest 12 bits = 0), create a chunk boundary. This produces variable-sized chunks whose boundaries are determined by the data, not by position.

Original:   [ Chunk A ][ Chunk B ][  Chunk C  ][ Chunk D ]
Insert 1 byte at start:
After:      [ Chunk A' ][ Chunk B ][  Chunk C  ][ Chunk D ]
              ↑ changed   ↑ same     ↑ same      ↑ same
Only ONE chunk re-uploaded! (Good)

Deep Dive #2

Content-addressable storage naturally enables deduplication: two blocks with the same SHA-256 hash are identical and stored only once, regardless of which user uploaded them.

Types of deduplication:

The upload dedup flow:

1. Client computes SHA-256 hashes for all blocks.
2. Client sends the list of hashes to the Block Server: "Which of these do you need?"
3. Block Server checks its hash index. Returns only the hashes that don't exist.
4. Client uploads only the missing blocks.
5. For already-existing blocks, the upload is "free" — no data is transferred.

At Dropbox scale, ~60% of uploaded blocks already exist. This means 60% of upload bandwidth is saved — a massive cost reduction.

Deep Dive #3

When two devices edit the same file offline and then both sync, we have a conflict. The journal detects it — both devices submit changes with the same previous_block_list — but how do we resolve it?

Dropbox's approach: last-writer-wins + conflict copy.

1. D1 uploads first → its version becomes the "latest" in file_metadata.
2. D2 uploads second → Metadata Server detects that D2's base version (journal ID 40) doesn't match the current latest (journal ID 42, from D1's upload).
3. Instead of overwriting D1's version, the server creates a conflict copy: project-proposal (D2's conflicted copy 2025-03-17).docx.
4. Both versions are preserved. The user manually resolves the conflict.

Why not automatic merge? Files are opaque binary blobs (not text). You can't merge two versions of a .docx or .psd file automatically. For text files, Dropbox could theoretically use OT (Operational Transform) or CRDTs, but they chose simplicity: save both versions, let the user decide.

IF submitted.previous_journal_id != file_metadata.latest_journal_id:
    → CONFLICT: another device edited the file between this device's last sync and now.
    → Create conflict copy with device name + timestamp.
    → Both versions are preserved as separate journal entries.
ELSE:
    → Normal update: create new journal entry, update latest_journal_id.

Deep Dive #4

Dropbox stores sensitive user data — the encryption model must protect against both external attackers and internal access.

Encryption layers:

These open-ended topics test architectural judgment at the staff+ level.