Design Dropbox

Dropbox is a file hosting and synchronization service. A user installs a client on multiple devices (laptop, phone, web), drops files into a magic folder, and those files appear on every other device within seconds. The same abstraction also supports sharing, version history, and collaboration.

What makes the problem interesting is the combination of huge blob payloads, tight sync latency, and multi-device consistency. You have to hold a durable petabyte-scale file store, a strongly consistent metadata database, and a low-latency push channel to every connected client, all at once.

This walkthrough follows the Interview Framework and is sized for a 45 to 60 minute interview.

Phase 1: Requirements

Functional Requirements

1. Users can upload and download files of up to a few GB each through a desktop client, mobile app, or web app.
2. Files sync across a user's devices. A change made on one device propagates to the others within seconds.
3. Users can share files and folders with other users, with read or read-write permissions.
4. Version history. Users can view and restore previous versions of a file for a configured retention window (say 30 days).
5. Conflict handling. When two devices edit the same file while offline, both edits are preserved (typically as a "conflicted copy").

Out of Scope for the MVP

Mention and defer: full-text search, collaborative in-place editing (that is Paper or Docs), trash/recycle bin, mobile thumbnails, team admin console, enterprise audit logs.

Non-Functional Requirements

1. Scale: 500M+ users, on the order of a trillion files, hundreds of PB of stored bytes.
2. Durability: at least 99.999999999% (11 nines). Losing a customer file is unacceptable.
3. Availability: 99.99% on the metadata and notification paths; 99.9% on the bulk transfer path.
4. Sync latency: p95 under 5 seconds from "file saved on device A" to "file visible on device B" for files under a few MB.
5. Consistency: metadata is strongly consistent per user. Block storage is eventually consistent across regions but durable on first write.
6. Bandwidth efficiency: only changed parts of a file should transfer, not the whole file.

Capacity Estimation

Assume a large consumer service:

Phase 2: Data Model

Core Entities

User(
  user_id UUID PK,
  email VARCHAR UNIQUE,
  created_at TIMESTAMP
)

Device(
  device_id UUID PK,
  user_id UUID FK,
  platform ENUM('desktop','ios','android','web'),
  last_seen_at TIMESTAMP,
  push_endpoint VARCHAR
)

Namespace(
  namespace_id BIGINT PK,         -- a root folder, owned by a user or a shared folder
  owner_user_id UUID,
  shared BOOLEAN,
  quota_bytes BIGINT
)

File(
  file_id UUID PK,
  namespace_id BIGINT FK,
  parent_path TEXT,               -- logical folder path
  name TEXT,
  current_revision_id UUID,
  is_deleted BOOLEAN,
  created_at TIMESTAMP,
  updated_at TIMESTAMP,
  UNIQUE(namespace_id, parent_path, name)
)

FileRevision(
  revision_id UUID PK,
  file_id UUID FK,
  size_bytes BIGINT,
  content_hash CHAR(64),          -- SHA-256 of full file
  block_manifest JSONB,           -- ordered list of block hashes
  modified_by_device_id UUID,
  created_at TIMESTAMP
)

Block(
  block_hash CHAR(64) PK,         -- content-addressed: SHA-256 of block bytes
  size_bytes INT,
  storage_ref TEXT,               -- pointer into blob store
  refcount BIGINT,                -- number of revisions referring to this block
  created_at TIMESTAMP
)

Share(
  share_id UUID PK,
  namespace_id BIGINT,
  path TEXT,                      -- file or folder being shared
  shared_with_user_id UUID,
  permission ENUM('read','write'),
  created_at TIMESTAMP
)

SyncCursor(
  device_id UUID,
  namespace_id BIGINT,
  last_delta_seq BIGINT,          -- monotonic per-namespace change counter
   (device_id, namespace_id)   
)

Relationships

• One User owns one personal Namespace and may be a member of many shared namespaces.
• One Namespace contains many File rows organized by parent_path and name.
• One File has a linear chain of FileRevision rows; only the latest is "current."
• One FileRevision references many Block rows through its manifest; blocks are shared across revisions and across users.
• SyncCursor tracks what each device has seen, so the server can ship only deltas since the last sync.

Block Size

Dropbox historically uses 4 MB blocks. The trade-off:

• Smaller blocks (e.g. 256 KB): better dedup granularity, finer delta sync, but more metadata rows and more round trips per file.
• Larger blocks (e.g. 16 MB): cheaper metadata, worse dedup on small edits, more network waste when a block changes.

4 MB is the common sweet spot for mixed office-document and media workloads.

Phase 3: API Design

Protocol Choice

• Client to API: REST over HTTPS for uploads, downloads, and metadata CRUD. Large uploads use chunked, resumable transfer.
• Push channel: a long-lived connection (WebSocket or long-poll) for sync notifications.
• Internal: gRPC between metadata, block, and notification services for typed, low-latency calls.

Upload

POST /v1/files/commit_batch
Body:
{
  "namespace_id": 123,
  "path": "/projects/report.docx",
  "block_manifest": [
    "sha256:aaa...",
    "sha256:bbb...",
    "sha256:ccc..."
  ],
  "size_bytes": 9500000,
  "client_modified_at": "2026-04-21T12:00:00Z",
  "parent_revision_id": "rev-abc"
}

Before calling commit, the client runs a "have these blocks?" check and only uploads missing ones:

POST /v1/blocks/missing
Body: { "block_hashes": ["sha256:aaa...", "sha256:bbb...", "sha256:ccc..."] }
Response: { "missing": ["sha256:ccc..."] }

PUT /v1/blocks/sha256:ccc...
Body: <raw block bytes>
Response: 201 Created

Then commit creates the new FileRevision referencing the manifest.

Download

GET /v1/files/{file_id}?revision_id=...
Response: { "block_manifest": [...], "size_bytes": ... }

GET /v1/blocks/{block_hash}
Response: raw bytes, served from CDN when possible

Sync Delta

POST /v1/sync/list_delta
Body: { "namespace_id": 123, "cursor": "seq:9_817_234" }
Response:
{
  "changes": [
    { "type": "add",    "path": "/a.txt", "revision_id": "..." },
    { "type": "modify", "path": "/b.txt", "revision_id": "..." },
    { "type": "delete", "path": "/old/c.txt" }
  ],
  "cursor": "seq:9_817_301",
  "has_more": false
}

Push Notifications

WS /v1/sync/listen
Server sends: { "namespace_id": 123, "latest_seq": 9817301 }
Client reacts by calling list_delta.

Sharing

POST /v1/sharing/invite
Body: { "path": "/projects/report.docx", "invitee_email": "a@b.com", "permission": "write" }

Phase 4: High-Level Design

Architecture

Write Flow (Desktop Sync Engine)

1. The local watcher detects a changed file. The sync engine splits the file into 4 MB blocks and hashes each block with SHA-256.
2. The engine computes a diff against the last known revision: a list of block hashes, some already present on the server, some new.
3. Engine calls blocks/missing to learn which hashes are new and uploads only those via PUT /v1/blocks/{hash}. Uploads run in parallel with a small pool (say 4 to 8 connections).
4. Once all new blocks are durable, the engine calls files/commit_batch with the full manifest, the previous revision ID (for optimistic concurrency), and timestamps.
5. The metadata service writes a new FileRevision, updates File.current_revision_id, bumps the per-namespace DeltaLog sequence, and enqueues refcount deltas for each referenced hash (see the GC section below on why refcount updates are batched rather than transactional).
6. The metadata service publishes a notification (namespace + new sequence) to the notification gateway.

Push + Pull Read Flow

1. Every online device holds an idle connection to the notification gateway. On sign-in, the client registers with its last-known cursor per namespace.
2. When the DeltaLog ticks, the gateway finds all connected devices subscribed to that namespace and pushes a tiny "new seq available" message.
3. The client calls sync/list_delta with its cursor and receives only the changed paths.
4. For each changed path, if content is needed locally, the client fetches the blocks it does not already have via GET /v1/blocks/{hash}, preferring the CDN edge. Blocks are immutable by hash, so CDN entries can carry very long TTLs and evict purely on capacity, not on invalidation.
5. The client reassembles the file and persists it to disk, then advances its cursor.

Conflict Resolution

Concurrent edits while offline are the hardest part. Dropbox uses optimistic concurrency with conflicted copies:

1. Each commit carries parent_revision_id. If that ID is no longer the current revision server-side, the commit fails with a conflict.
2. The losing client re-commits its local revision under a derived name such as report (Alice's conflicted copy 2026-04-21).docx. The server materializes this as a real entry in the namespace (new File row, new FileRevision, new DeltaLog sequence), so every device converges to seeing both files.
3. Both users now see both versions in their normal sync views and can merge manually. Nothing is lost.

Sharing Flow

1. User A invites User B to a folder. A new Share row links the folder's namespace to User B.
2. User B's next sync/list_delta on the shared namespace picks up every file that is currently in the folder.
3. Because all existing revisions already reference content-addressed blocks, no bytes re-upload and no new refcounts are needed. Adding the Share row is a single metadata write. This is what makes "share a 50 GB folder instantly" possible: granting access is O(1), regardless of folder size.

Phase 5: Scaling & Trade-offs

How the Design Meets NFRs

1. Durability: blocks are written to multi-AZ erasure-coded storage with per-block checksums; background scrubbers re-verify and repair. Metadata uses synchronous multi-replica commit.
2. Availability: metadata and block planes scale and fail independently. An outage on the block plane still lets the metadata plane serve sync-list queries (clients just cannot fetch bytes yet). An outage on the notification gateway degrades to client-side polling.
3. Sync latency: push notification carries only a cursor, so server-side fan-out (subscriber lookup + enqueue) is sub-millisecond. Actual delivery latency is bounded by each subscribing device's WebSocket RTT. The bulk of end-to-end latency is the client upload itself, which is bounded by block count and bandwidth, not server logic.
4. Bandwidth efficiency: block-level dedup + incremental sync makes most edits O(diff size), not O(file size).
5. Scale: metadata is sharded by user_id (or namespace_id for shared folders). Block store is flat and infinitely horizontal because keys are content hashes.

Scaling Each Layer

Reducing Sync Latency

• Upload in parallel. 4 to 8 concurrent block PUTs saturate most consumer links.
• Pipelined commit. The client can start commit_batch the moment the last block acknowledges; no need to wait for a separate confirmation step.
• Nearest region upload. DNS or a signed upload-host endpoint routes the client to the closest ingress. Blocks are durably persisted in at least one region before commit; cross-region replication for locality and DR happens asynchronously afterwards.
• Fast-path push. The notification gateway sits in front of a pub/sub bus fed directly from the metadata commit path. Server-side hop from commit to push is sub-millisecond; per-device delivery is bounded only by the subscriber's WebSocket RTT.
• Keep the block plane out of the critical metadata path. A slow block upload should not delay metadata reads for other users.

Garbage Collection of Blocks

Because blocks are deduped, you cannot delete a block just because its last referring revision was deleted. You need reference counting:

1. On commit, enqueue increments for every hash in the manifest. Hot templates (empty-file hash, common boilerplate) would otherwise drive heavy write amplification, so refcount deltas are batched and applied asynchronously rather than transactionally with the metadata commit.
2. On revision deletion (user deletes a file, or version-history retention expires), enqueue decrements for each referenced hash.
3. A background sweeper looks for blocks with refcount = 0 older than a grace period (to protect against races) and deletes them from the blob store.
4. The manifest set is the source of truth. A periodic full recount over the manifest table reconciles incremental refcounts and catches drift. Incremental refcount is an advisory index, not the ground truth.

Consistency and Trade-offs

Security Notes

• Authorization is metadata-level, not block-level. A user's ability to read block H is governed by the manifest they are authorized to read. The block service still checks that the caller has a signed short-lived token tied to that specific hash and revision.
• Dedup confirmation oracle. Global dedup has a well-known side channel: an attacker who already has a candidate file can probe blocks/missing and learn whether any user in the fleet stores it. The mitigation is to require a lightweight proof-of-possession on dedup hits (for example, a server-issued nonce the client must HMAC with the block bytes) before crediting the block reference. For sensitive tiers, scope dedup per-namespace instead of globally.
• Client-side encryption is optional and changes the dedup story: identical plaintext encrypted by different users produces different ciphertext, so cross-user dedup disappears. Enterprise tiers sometimes accept this trade.
• Shared link tokens are capability URLs; rotate them on permission revocation.

Deep Dive: Why Not Store Files as Single Blobs?

If you store a file as one opaque object, a 10 KB edit on a 1 GB file forces a full re-upload and a full new copy. Block-level chunking is what unlocks:

• Delta uploads: only changed blocks move.
• Cross-user dedup: duplicate content (forwarded attachments, shared templates) costs one copy across the fleet.
• Range reads for video/large-PDF preview: fetch only the needed blocks.

The cost is more metadata rows and more small GETs. For the Dropbox workload, the trade-off pays off.

Other Probes a Strong Interviewer Will Push On

Rename and move. These are metadata-only operations. The FileRevision manifest is unchanged, so no blocks move and no bandwidth is spent. The sync delta carries a rename event with both old and new paths so clients update locally without redownloading.

First-sync storm. When a user joins a 500K-file shared folder, the initial sync/list_delta returns pages of entries, and the client fetches blocks it does not already have. Pagination is mandatory; rate-limit the client's parallelism so one new member does not hot-spot the block plane.

Watcher reliability. FSEvents and inotify drop events under load and miss changes that happen while the client is stopped. The sync engine cannot trust the watcher alone: it runs a periodic full-tree hash scan to reconcile against the server manifest, and treats the watcher as a low-latency hint on top of that scan.

Permission revocation. Removing User B from a shared folder stops new sync but does nothing about bytes already on their disk. This is an accepted limitation, not a bug. Enterprise tiers layer on remote-wipe or DRM if they need stricter semantics.

LAN sync. Two desktops on the same network can exchange blocks directly using a local-discovery protocol, skipping the WAN for the block plane. Metadata still flows through the server so cursors and conflicts stay authoritative.

Bandwidth-aware throttling. The client caps upload and download rate per network (home vs office vs tether) and backs off under detected congestion. Otherwise a single large upload saturates the user's link and makes the product feel broken.

Common Pitfalls

Interview Checklist

Requirements

• Stated upload, download, sync, share, versioning as the core functional set
• Named 11-nines durability and 5-second sync latency as the pivotal NFRs
• Back-of-envelope: PB/day ingest, and the insight that metadata request rate is driven by idle clients while byte throughput is driven by real edits

Data Model

• User, Namespace, File, FileRevision, Block (content-addressed), Share, SyncCursor
• Explained the metadata / blob separation

API

• Block-missing + block PUT + manifest commit for upload
• Cursor-based sync list and a WebSocket push channel
• Sharing invite endpoint

High-Level Design

• Drew metadata plane, block plane, notification gateway, CDN
• Walked through write flow, read flow, conflict resolution
• Showed how sharing a 50 GB folder is a single metadata write, because existing revisions already reference the content-addressed blocks

Scaling & Trade-offs

• Per-layer bottleneck + fix table
• Sync latency reduction techniques (parallel blocks, nearest region, fast push)
• Block refcount GC and its failure modes
• Explicit trade-offs on consistency, conflict model, block size

Summary

The defining properties of this design: metadata and bytes scale independently, blocks are content-addressed and globally deduped, and the push channel carries cursors not data. Everything else follows from those three choices.