Design Dropbox

Question 1

What is doing the syncing?

Accepted Answer

The client is not a thin one here — it hashes, chunks and decides what to send. It belongs on the board.

Question 2

What do the devices connect to?

Accepted Answer

A gateway separates the two very different paths: small constant metadata calls, and large slow uploads.

Question 3

Where do the file contents live?

Accepted Answer

File bytes in a database is the classic mistake here — it makes backups enormous, replication slow and the whole thing expensive. Object storage is built for exactly this and nothing else is.

Question 4

Where do the file names, versions and chunk lists live?

Accepted Answer

The metadata is small, relational and queried on every sync check — the opposite of the bytes. Splitting them is the central decision in this design.

Question 5

A 2GB file finishes uploading. What happens before the other devices know?

Accepted Answer

Indexing, thumbnailing, virus scanning and notifying other devices are all work that should not sit inside the upload request. Enqueue it.

Question 6

Your client talks to the metadata store directly. What stops it reading another account’s file list?

Accepted Answer

Every metadata read is scoped to one account. That scoping is a service’s job, and a direct connection has nowhere to put it.

Question 7

How many uploads a second?

Accepted Answer

500,000,000 / 86,400 is about 5,800 a second. At 1MB each that is roughly 5.8 GB/s of ingest — the number that says the bytes cannot go anywhere near your database.

Question 8

Someone edits one line of a 2GB file. What goes over the wire?

Accepted Answer

Chunking with content hashes is the answer to three problems at once: only changed chunks are sent, identical chunks are stored once across every user, and a dropped connection resumes at a boundary instead of starting over.

Blueprint — system design