Loading…

The decisions that matter

Content-addressed blocks, uploaded straight to object storage.Small edits and dropped uploads send only what is missing.
A conditional commit on the base version.Two devices can’t both win silently; the second becomes a conflicted copy.
An ordered change log per namespace, a position per device.Absent devices read exactly what they missed.
Deletes and versions as records, blocks freed by reference.Restore works for 30 days, and cleanup can’t break a shared block.
One home region per folder tree, under a fenced lease.One region decides a folder’s saves; each confirmed save has a second copy.

Architecture diagramThe final design at a glance

Block bytes go straight to object storage; the metadata database orders each folder’s saves and keeps its log, and records and new blocks reach a second region before a save is confirmed. Dashed lines are asynchronous.

Diagram as text

Components: Notification service (Notifications); Laptop, phone and web (Client); Metadata service (Service); Metadata DB: tree, versions, change log (SQL DB); Second region: records and blocks (Component); Block service (Service); Object storage: blocks by hash (Object store); Cleanup and tiering (Worker). Connections: Notification service → Laptop, phone and web (look now), asynchronous; Laptop, phone and web → Metadata service (commit, read changes); Laptop, phone and web → Block service (which blocks are missing?); Laptop, phone and web → Object storage: blocks by hash (block bytes, signed URLs); Metadata service → Metadata DB: tree, versions, change log (conditional commit + log entry); Metadata DB: tree, versions, change log → Second region: records and blocks (records, before confirm); Object storage: blocks by hash → Second region: records and blocks (new blocks, before confirm); Metadata service → Notification service (folder changed), asynchronous; Block service → Object storage: blocks by hash (verify, publish if absent); Cleanup and tiering → Object storage: blocks by hash (free unused, tier cold), asynchronous.

Understanding the problem

A file sync service keeps a folder the same on a person’s laptop, phone, tablet and the web. Saving is almost the only action, but it carries hard promises: offline edits on two devices both survive, a device off for weeks catches up exactly, a small edit to a huge file doesn’t resend it, and a removed teammate loses access at once. This page designs the family’s one variant, Cloud drive.

The practice brief states the requirements up front; confirm them in the first few minutes. The core is the path from a save on one device to the others.

Functional requirements

CorePeople install the app on several devices, and a file saved in the synced folder appears on their other devices.
CorePeople can edit files offline; the changes sync when the device reconnects.
CorePeople can browse, upload and download files on the web.
CorePeople can see earlier versions of a file and restore one, and restore deleted files, for 30 days.
CorePeople can share a folder with others as viewers or editors, and remove them.
Below the lineSharing a link to a single file.
Below the lineSearching file names.
Below the lineComments on files.
Below the lineSelective sync and online-only files.A client choice about what to download, from the same log and block lists.
Below the lineWatching the local folder.Each operating system differs. Say the client notices and hashes changed files.
Below the lineCamera uploads.One-way uploads that reuse the save path.

Non-functional requirements

ConsistencyNo edit is ever silently lost: if two devices change the same file before either has synced, both versions survive and the person can see that it happened.
LatencyChanges reach a person's online devices within a few seconds.
QualityA device that was offline for weeks catches up without downloading everything again.
QualityA small edit to a big file, or a dropped connection, never sends the whole file again.
DurabilityOnce a save is confirmed, it is never lost.
AvailabilityThe service stays available (99.99%), even while a whole region is down.

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 500 million accounts; about 100 million people active a day, with about 3 devices each.
ScaleAbout 1 billion file saves a day, most of them small; files up to 50 GB.
ScaleAbout an exabyte stored.
ScaleShared folders with up to millions of files and hundreds of members.

Out of scope

Out of scopeSeveral people typing in the same document at once (live co-editing).
Out of scopeFull-text search inside files, previews and thumbnails.
Out of scopeEnd-to-end encryption.
Out of scopeSign-up, plans and billing.

Check yourself

Live co-editing is out of scope. What does that let you assume about a save?
Show answerHide answer
A save is a whole new version made from one earlier version. The server only has to notice when two saves came from the same version and keep both; it doesn’t merge keystrokes.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Work out only the numbers this design depends on, with one line of working each. The average save size is an assumption to say out loud.

Back of the envelope for the cloud drive

Quantity	Value	Working
Saves	About 11,600 a second; about 35,000 at peak	A billion a day ÷ 86,400; a busy hour at three times that.
New data uploaded	About 46 Gbps	About 0.5 MB per save × 11,600 a second.
New storage	About 500 TB a day	Before dedupe and compression, on top of an exabyte.
Devices online	About 90 million	About 30% of the 300 million devices in use.
Device updates	About 23,000 a second	Each save reaches the owner’s two other devices, more when shared.
Blocks in a 2 GB file	About 500	At 4 MB a block; a small edit changes one to three.

What the numbers tell you

Saves are small and frequent, so a commit is a small metadata write.
Tens of millions of devices wait at once, on held connections that carry no data.
Storage grows by hundreds of terabytes a day, so storage classes belong in the design.

Read:Learn: Numbers and capacity estimation

Try it: The numbers that shape the designGuided practice · File sync, Cloud drive · Senior

Check yourself

Which number sizes the notification tier, and which one drives the bill?
Show answerHide answer
Devices online at once size the notification tier: tens of millions of held connections. Daily storage growth drives the bill, because it compounds on top of an exabyte.

Core entities

Start from the reads: list a folder, open a file, show versions, read changes after a position, check access. A namespace is an account’s tree or one shared folder and owns its items, members and log, as in Dropbox’s 2014 post (Dropbox tech blog (opens in a new tab)). A version holds an ordered list of block hashes; only the bytes live in object storage.

The records that matter

Record	Key fields	Why it exists
Namespace	`namespace_id`, owner, `home_region`	An account’s tree or one shared folder; it orders its own changes.
Item	`namespace_id`, `item_id`, `parent_id`, name, `current_version`	Files and folders, listed by parent; a move changes one row.
Version	`item_id`, `version`, `base_version`, `block_list`, `client_save_id`	One row per save, kept 30 days.
Change	`namespace_id`, `seq`, `item_id`, kind	The ordered log devices read after their position.
Block	`hash`, size, `ref_count`	Content stored once, however many files use it.
Member	`namespace_id`, `user_id`, role, `mount_path`	Who sees a shared folder, and where it appears.

Where each kind of data lives

Data	Store	Why
Everything above but blocks	A strongly consistent, transactional database split by namespace: Spanner, CockroachDB, or sharded MySQL or PostgreSQL	A save changes an item, a version and the log together.
Block index and counts	The same database, or a table sharded by hash	Answers "which blocks are missing?" and drives cleanup.
Block bytes	Object storage keyed by hash: S3, Google Cloud Storage or Ceph	Large, written once, cheap per byte.

Architecture diagramRecords in one store, bytes in another

Read:Learn: Data model design Learn: Storage choice justification Learn: S3 / Blob Storage

Try it: Files, folders, versions and sharesGuided practice · File sync, Cloud drive · Senior

Check yourself

Why split the metadata by namespace rather than by user?
Show answerHide answer
A shared folder is one tree that many people see. Keyed by namespace, a commit is one transaction in one place; keyed by user, one edit would touch every member’s rows.

The API

Two kinds of traffic: small metadata calls, and block bytes that go straight to object storage through short-lived signed URLs. A commit carries a client_save_id the app picks once per save, so a repeat returns the version already made.

The calls the app and the web make

Call	Request	Response	Errors
`POST /v1/blocks/missing`	Block hashes	Missing hashes with signed upload URLs	`401`, `413`
`POST /v1/commit`	`namespace_id`, path, `base_version`, `block_list`, `client_save_id`	The new version, or the conflicted copy saved	`403`; `409` blocks missing
`GET /v1/changes`	`namespace_id`, `after`	Entries after it, the new position, `has_more`	`410` position too old
`GET /v1/notify`	Namespaces and positions	Held open, then "look now"	Early return with a back-off
`GET /v1/blocks/{hash}`	None	A signed URL, valid a minute at most	`403` without read access
`GET /v1/folders/{id}/children`	`cursor`	A page of items, `next_cursor`	`403`, `404`
`DELETE /v1/files/{id}`, `POST …/restore`	None, or `version`	`204`, or a new version	`410` after 30 days
`POST`, `DELETE /v1/folders/{id}/members`	Person and role	`201`, `204`	`403` unless you manage it

Read:Learn: API contract design Learn: Idempotency and retries

Try it: The API for the app and the webGuided practice · File sync, Cloud drive · Senior

Check yourself

The phone’s commit times out and it sends the same commit again. What stops a second version?
Show answerHide answer
The same client_save_id. The server finds it on the version it made and returns that version, so the retry is neither a duplicate nor a false conflict.

High-level design

Build the design one flow at a time; the deep dives then harden the parts an interviewer pushes on.

Save on the laptop

Say a person edits a few pages of a 2 GB file, for example. The app splits it into blocks named by their hash and sends only what the server lacks; Dropbox describes 4 MB blocks hashed with SHA-256 (Dropbox tech blog (opens in a new tab)).

The app hashes each block and asks the block service which hashes are missing: for a few pages, two or three.
It uploads only those, to temporary keys with signed URLs; after a drop, it resends only unfinished blocks.
The block service checks each block against its hash and size, then publishes it under that name only if none exists yet.
The app commits the new version as the ordered list of hashes, naming the version it was made from.
In one transaction, the metadata database records the version and appends a change-log entry.

Architecture diagramSave on the laptop: only the missing blocks

Only missing blocks are uploaded, straight to object storage; the commit is a list of hashes, so no file bytes touch the metadata service.

Diagram as text

Components: Laptop app (Client); Block service (Service); Object storage (Object store); Metadata service (Service); Metadata DB (SQL DB). Connections: Laptop app → Block service (1. which hashes are missing?); Laptop app → Object storage (2. PUT missing blocks to temporary keys); Block service → Object storage (3. check hash, publish if absent); Laptop app → Metadata service (4. commit: block list, base version); Metadata service → Metadata DB (5. version and log entry, one transaction).

Read:Learn: Large file upload & blob handling Learn: S3 / Blob Storage

Try it: Save on the laptop, open on the phoneGuided practice · File sync, Cloud drive · Senior

Keep reading+1 min

Publishing a block safely

Blocks are shared, so a buggy or malicious client mustn’t be able to write the bytes behind a hash someone else relies on. Upload to a temporary key, check the hash and the signed size, then publish with a create-if-absent write. S3 accepts a write with If-None-Match: * only when no object with that key exists (Amazon S3 docs (opens in a new tab)), and Google Cloud Storage does the same with a generation-match precondition of 0 (Google Cloud docs (opens in a new tab)).

Open it on the phone and the web

The phone learns that something changed, reads what changed, and fetches only the blocks it lacks. The web app uses the same calls without a local copy: it lists folders in pages, downloads through a signed URL that streams the file’s blocks, and uploads blocks from the page.

The notification service, holding a connection from each online device, wakes the phone: "look now".
The phone asks for the changes after its position and gets the new version’s block list.
It downloads only the blocks it lacks, through signed URLs and a CDN, rebuilds the file and stores its new position.

Architecture diagramOpen it on the phone: fetch only what is missing

Design Dropbox

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

The API

High-level design

Save on the laptop

Publishing a block safely

Open it on the phone and the web

Sign in with Google to read the rest

Practise this

Fixed blocks or content-defined chunks

Choosing a block size

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

04The API

05High-level design

Save on the laptop

Publishing a block safely

Open it on the phone and the web

Sign in with Google to read the rest

12Practise this

Fixed blocks or content-defined chunks

Choosing a block size

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this