Design Dropbox

Problem Design a Dropbox-style file storage and sync service, covering the HLD and the client/metadata details usually probed as LLD.

Functional requirements

• Upload/download files; sync a user's folder across devices automatically; version history and restore; share folders (extension). Offline edits reconcile on reconnect.

Non-functional requirements

• Large files (GBs) and many small ones; sync latency in seconds; upload resumability; storage efficiency via dedup; scale to discuss: hundreds of millions of users, exabyte-class blob storage.

Key components

• Client: watcher (FS events) → chunker (fixed ~4MB or content-defined chunks) → hasher (SHA-256 per chunk) → sync engine with a local metadata DB; uploads only chunks the server doesn't have (hash check first) — resumable and dedup-friendly.
• Server: block/blob store for chunks (S3-style, content-addressed by hash); metadata service (file → ordered chunk hashes, versions, namespaces) on a sharded relational store; notification service (long-poll/WebSocket) telling other devices "namespace changed, sync"; processing queue decoupling upload from metadata commit.

Deep dives / trade-offs

• Delta sync: editing 1MB of a 1GB file re-uploads only affected chunks — why chunking granularity matters (content-defined chunking survives insertions; fixed chunking doesn't).
• Conflict resolution: no locks — last-writer-wins is lossy, so create a "conflicted copy" on concurrent edits (vector clock / version-per-device detection); walk through the two-devices-offline scenario.
• Dedup security nuance (cross-user dedup + hash oracle), metadata DB sharding by namespace, cold-storage tiering for old versions.