Dropbox System Design

Introduction

You edit a slide deck on the train—offline. Your colleague saves a new version from the office at the same moment. Both laptops sync. One file wins. The other becomes report (conflicted copy).pptx. Neither of you planned for that—but the product must not lose bytes.

That is what users feel. The interview asks whether you can separate what changed in the folder tree from where the bytes live.

Dropbox-class systems are two-layer: a metadata plane (trees, versions, ACLs, journal) and a blob plane (content-addressed, cheap, replicated object storage). Interviewers watch whether you chunk and dedupe before you talk about databases, and whether you separate “what changed” from “where the bytes live.”

Weak answers stop at “S3 for files, Postgres for metadata.” Strong answers walk sync (cursor, conflicts), sharing (ACL on every read), and GC (chunk refcount after delete).

If you remember one thing: Metadata journal + content-addressed chunks—two planes, one sync story.

How to approach

Walk one file from laptop to cloud to phone—not “we use object storage.”

Clarify real-time co-editing vs file sync—scope changes the answer. Sketch namespace per user or team, change journal with monotonic seq, chunk upload with content hash, then conflict policy. Search is async—mention after core sync.

In the room: “I’ll confirm sync vs live co-edit scope, then walk chunk upload and journal commit before sharing and search.”

If you remember one thing: Scope first, then journal + chunks + conflict policy.

Interview tips

Five exchanges that test sync depth—not storage name-dropping.

Content addressing and dedup

You: “We store files in S3 by path.”

They ask: “Two users upload the same 2 GB installer—do you pay twice?”

Land here: Split files into chunks named by hash. Server skips upload if chunk exists. Refcount chunks for garbage collection after delete.

Timestamps vs journal

You: “We sync by comparing modified times.”

They ask: “Two offline edits, clocks skewed—who wins?”

Land here: Server journal sequence (seq) is authoritative for “what changed.” Use parent_rev on commit for optimistic concurrency—not mtime alone.

Sharing and ACLs

You: “Shared folder means everyone can read.”

They ask: “User revokes share—how fast does access actually stop?”

Land here: Effective permission = ACL + inheritance. Cache per-user permission views with TTL; revoke must invalidate quickly on the read path.

Large file bandwidth

You: “Re-upload the whole file on every change.”

They ask: “User tweaks one slide in a 500 MB deck?”

Land here: Chunk-level sync—only missing hashes upload. Mention delta/rsync-style block diff if pressed; at minimum chunk list diff.

Huge folder listing

You: “GET /folder returns all children.”

They ask: “Folder with a million files?”

Land here: Pagination, cursor, lazy expansion—never one response with every child.

If you remember one thing: Name hash, seq, parent_rev, ACL check, cursor—not “we’ll CDN it.”

Capacity estimation

Implications: Metadata QPS drives sharding; hot folders need rate limits and efficient fan-out of change notifications.

If you remember one thing: Metadata QPS and egress dollars matter more than raw blob storage capacity.

High-level architecture

Desktop/mobile clients keep a local mirror + journal cursor. Metadata service (strongly consistent per shard) owns paths, file versions, chunk lists, sharing edges. Blob storage (S3-class) stores immutable chunks by hash. Notification service tells clients “something changed” so they pull delta from metadata API. Search indexer consumes async events—off hot path.

Who owns what:

• Metadata API — Authoritative tree; transactional commit of new version; lists changes since cursor.
• Chunk gateway — Pre-signed uploads; verifies hash on complete; dedup skip if chunk exists.
• Object store — Durability; lifecycle to cold tier; encryption at rest.
• ACL service — Resolves share → effective access; cached with careful invalidation.

[ Client A ] ──sync──► [ Metadata svc ] ──► [ Metadata DB / shard ]
      |                      |
      | 1) list changes      +-- journal (seq, ops)
      | 2) get chunk hashes
      v
[ Pre-signed GET/PUT ] ──► [ Object store (chunks by hash) ]
      ▲
      |
[ Client B ] ◄──notify── [ Notification svc ] (WebSocket / FCM)

In the room: Say async clearly: commit returns fast; search index and thumbnails trail; sync correctness does not wait on thumbnail.

If you remember one thing: Notify → client pulls delta from metadata; blobs flow separately by hash.

Core design approaches

Metadata model

File: (namespace_id, path) → file_id → version → ordered chunk hashes + size + content hash of whole file (optional).

Folder: Tree node with children listing or materialized path table—trade join cost vs rename cost.

Sync strategies

Polling: Simple; wasteful at scale—use cursor or long poll.

Push notification: “Something changed in namespace” → client pulls delta—scales better than pushing full trees.

Conflict

LWW with server timestamp + conflict file foo (conflicted copy).txt—honest UX.

CRDT for text—only if real-time co-editing in scope—heavy.

If you remember one thing: Push “something changed” + client pull journal beats pushing full trees.

Detailed design

Write path (upload new version)

1. Client splits file into chunks, computes SHA-256 per chunk.
2. Client requests upload for missing hashes (server returns skip for dedup).
3. PUT chunks to object store with pre-signed URLs.
4. Client calls commit: {path, parent_rev, chunk_list, client_rev}—server transactionally creates new version if parent matches; else conflict response.

Read path (another device sync)

1. Client maintains last_seq for namespace.
2. GET /changes?since=seq returns ops: add/update/delete/move.
3. For each updated file, fetch chunk list if not cached locally; download missing chunks.

Sharing

POST /share creates edge (resource, grantee, role); read path checks grantee + inheritance; public link is separate token with scoped permission.

In the room: Walk upload: chunk → hash → prepare → PUT missing → commit with parent_rev. Other device: notify → GET /changes?since=seq → fetch missing chunks.

If you remember one thing: Write = chunks then commit; read = journal cursor then parallel chunk GET.

Key challenges

• Conflict detection: Optimistic concurrency with rev; merge is product problem—technical answer is detect + surface.
• Dedup GC: Delete file decrements refcounts; sweep unreferenced chunks async—race with concurrent uploads—transaction or epoch GC.
• Rename/move at scale: Single metadata txn per namespace shard; hot dirs need care.
• Share link abuse: Rate limit; virus scan async; DLP enterprise—brief mention.

If you remember one thing: Conflicts detect with parent_rev; dedup GC needs refcount discipline under concurrent uploads.

Scaling the system

• Shard metadata by namespace (user/team); avoid cross-shard moves or two-phase commit—design paths to stay in-shard when possible.
• Horizontal stateless metadata API with connection pooling to shards.
• Object store scales itself; hot chunks may need CDN for shared links.
• Rate limit sync list for noisy clients; bulkhead tenants.

If you remember one thing: Shard metadata by namespace; object store scales itself; hot folders need pagination and rate limits.

Failure handling

Degraded UX: Stale file list briefly; outage is cannot access files—metadata HA matters more than blob (blobs are already replicated).

If you remember one thing: Partial uploads get lifecycle TTL; commit conflicts return 409—client merges or saves conflict copy.

API design

Chunk upload

File commit

POST /v1/files:commit
{
  "path": "/docs/report.pdf",
  "parent_rev": "abc",
  "chunks": ["sha256:...", "..."],
  "client_rev": "uuid"
}

Change feed

Diagram:

Client --GET /changes?cursor=...--> Metadata
         |
         +-- ops: file X v3, new chunk hashes [h1,h2]
         |
Client --GET missing chunks--> Object store (parallel)

Errors: 409 conflict on parent_rev; retry with merge UX; 412 if quota exceeded.

If you remember one thing: Hottest path is changes feed + parallel chunk fetch—design APIs around cursor pagination.

Production angles

[ Many clients poll /changes ] → metadata QPS ↑
        → throttle noisy clients → 429 + Retry-After

Bottlenecks and tradeoffs

Consistency vs availability across shards

The tension — Strong per-namespace serializability is expensive cross-shard.

What breaks — Cross-shard moves need two-phase commit or careful path design.

What teams do — Scope moves to stay in-shard when possible; accept eventual cross-shard consistency for rare ops.

Say in the interview — Namespace sharding is a product constraint, not an afterthought.

Dedup vs privacy

The tension — Cross-user dedup saves storage but reveals shared chunks exist.

What breaks — Enterprise customers disable dedup; GC graphs get harder.

What teams do — Per-tenant dedup pools; product flag for “no cross-user dedup.”

Say in the interview — Name the privacy cost of global content addressing.

If you remember one thing: Metadata is the hot path; blobs are immutable; sync loops and GC backlog are ops reality.

What should stick

You do not need to memorize every service. After this guide, you should be able to:

1. Two planes — Metadata journal vs content-addressed chunks in object storage.
2. Chunk + hash + dedup — Upload missing hashes only; refcount for GC.
3. Journal beats mtime — seq cursor and parent_rev for conflicts—not clock compare alone.
4. Notify then pull — Push says “something changed”; client pulls delta cheaply.
5. 409 is a feature — Conflict detection is technical; merge UX is product.

Tell it in the room: “Client chunks file, uploads missing hashes, commits version with parent_rev. Other devices get notify, pull changes since cursor, fetch missing chunks in parallel. Sharing checks effective ACL every read. Deletes decrement refcounts; GC sweeps unreferenced chunks async.”