Design Dropbox / Google Drive — Cheat Sheet

A file sync service stores users’ files durably and keeps them consistent across all their devices. The core insight is to split the problem in two: tiny, structured metadata (who owns what, folder tree, versions) lives in a database, while the large, opaque file bytes are chunked and stored in an object store. Sync is then a matter of shipping only the chunks that changed.

• ✓Upload and download files of arbitrary size (up to a few GB)
• ✓Sync files automatically across all of a user’s devices
• ✓Share files and folders with other users (view / edit)
• ✓File versioning — restore a previous version
• ✓Folder hierarchy, rename, move, delete (with trash)
• ✓100M users, ~1B files, petabytes of data

• ✓Users: 100M total, ~10M daily active
• ✓Files: ~1B files, avg 1MB → ~1 PB raw
• ✓Chunk size: 4 MB fixed blocks
• ✓Dedup savings: ~30–50% on shared/duplicate content
• ✓Metadata / file: ~1 KB → ~1 TB metadata total

• ✓Client + Local Sync Agent — A background agent watches the local folder, splits changed files into 4MB chunks, computes each chunk’s hash, and uploads only chunks the server doesn’t already have. It also listens for change notifications to pull remote updates.
• ✓API Gateway / Load Balancer — Terminates TLS, authenticates the device token, rate-limits, and routes metadata calls to the Metadata Service and byte transfers to the Block Service.
• ✓Metadata Service (relational DB) — Stores the file/folder tree, versions, chunk lists, and sharing ACLs in a sharded PostgreSQL / relational database. Small, highly structured, transactional — the source of truth for "what the file looks like now".
• ✓Block / Object Store (S3) — Stores the actual 4MB chunks in Amazon S3 (or equivalent object storage), keyed by content hash. Cheap, effectively infinite, 11-nines durable. Chunks are immutable and content-addressed, which gives free deduplication.
• ✓Notification Service — When a file changes, pushes a lightweight "something changed" event to the user’s other online devices over a long-lived connection (WebSocket / long-poll). Offline devices reconcile via a delta query on next launch.
• ✓Cache (Redis) — Caches hot metadata (folder listings, recent file versions) and chunk-existence lookups so the common "does this chunk already exist?" check never hits the database.

• ✓Where do the file bytes live? → Object store (S3), not the database: Blobs are huge, immutable, and opaque — an object store gives cheap, 11-nines-durable, infinitely scalable storage. The DB only holds the chunk-hash list.
• ✓Fixed 4MB chunks vs. whole-file transfer → Fixed chunks + content-addressed dedup: Editing one byte of a 1GB file re-uploads one 4MB chunk, not 1GB. Identical chunks are stored once, saving 30–50% of space.
• ✓Metadata store: SQL vs. NoSQL → Sharded relational (SQL): Folder moves/renames and version commits need multi-row transactions and a consistent tree. Relational integrity is worth more here than raw write scale.
• ✓Push notifications vs. polling for sync → Long-lived push + delta query: Polling 10M devices every few seconds is wasteful and slow. A push "something changed" + a cursor-based delta query is efficient and resumable.

• ✓Lead with the metadata-vs-blocks split — it’s the core insight and interviewers wait for it.
• ✓Explain chunking in terms of the "edit one byte of a huge file" scenario — it makes the 4MB block choice obvious.
• ✓Content-addressed storage (hash = key) gives dedup for free — call this out explicitly.
• ✓For sync, describe the Notification Service + cursor-based delta query rather than polling.
• ✓Be honest about conflicts: binary files get a "conflicted copy"; real merging (CRDTs) is a separate, harder problem.
• ✓Mention durability (11 nines) and how the object store, not your app, provides it.