Design Google Drive / Dropbox

Design a file storage and sync service like Google Drive or Dropbox: users upload files, access them from any device, and changes sync automatically.

1. Clarify the requirements

Before drawing anything, ask questions. These are the answers an interviewer would typically give:

How many users?

50 million signed-up users, 10 million daily active.

Storage per user?

10 GB free.

File sizes?

Any type, up to 10 GB; average 500 KB.

Which features?

Upload/download, sync across devices, notifications of changes, file revisions, sharing. Real-time collaborative editing is out of scope.

Uploads per day?

Each active user uploads 2 files a day.

Consistency?

Strong consistency for metadata: all devices must see the same file state.

2. Estimate the scale

Assumptions: 50M users, 10M DAU, 10 GB quota each, 2 uploads per DAU per day.

• Total space allocated: about 500 PB50M × 10 GB = 500 PB.
• Upload QPS: about 231 uploads/s10M × 2 ÷ 86,400 ≈ 240/s (peak ≈ 480).

3. The high-level design

1. Clients reach two kinds of serversAPI servers handle metadata (files, folders, sharing); block servers handle file content. A load balancer sends each request to the right pool.
2. Metadata needs strong consistencyTwo devices editing the same folder must agree: file metadata lives in a relational database with ACID transactions, cached for reads.
3. Blocks in object storageFile blocks go to object storage, replicated across regions; rarely used files move to cheaper cold storage.
4. Tell other devices about changesWhen a file changes, an event goes on a queue; a notification service tells the user's other devices (long polling) to pull the new version.
5. Watch it in productionMetrics and alerts close the loop: sync latency, upload failures and storage growth.

4. The components and what each one does

Desktop & mobile clients Client (web)

Split files into 4 MB blocks; upload only changed blocks (delta sync).

Load balancer Load balancer

Spreads requests over the stateless servers behind it, health-checks them and routes around a dead one. Rate limits abusive clients.

API servers App servers

Sign-in, file metadata, sharing and version history. Stateless.

Block servers Service

Receive blocks, compress and encrypt them, store them; dedupe by block hash.

Metadata DB SQL database · MySQL

Users, files, versions, block lists. ACID; sharded by user; replicas with failover.

Block storage Object storage · S3

Encrypted blocks, replicated across regions; cold tier for old files.

Notification service Workers

Long polling: tells other devices a file changed. Offline devices catch up when they reconnect.

Metrics & alerts Metrics & alerts

Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.

5. Deep dive: sync, blocks & conflicts

How do you upload and sync large files efficiently, notify other devices of changes, and resolve conflicting edits?

• Split files into blocks (e.g. 4 MB), hash each; upload only changed blocks (delta sync), compressed and encrypted.
• A notification service (long polling) tells other clients when to pull changes.
• First version processed wins; conflicting copies are saved for the user to merge.

6. What interviewers listen for

• Upload (resumable), download and revision APIsSimple + resumable uploads, download, list revisions.
• Metadata model: file, version, blockfile, file_version, block (hash, order) tables.
• Delta sync: only changed blocksRe-uploading a 1 GB file for a 1-byte change wastes bandwidth.
• Conflict resolutionTwo offline edits to the same file: first processed wins; the other becomes a conflict copy.
• Offline clients catch up (offline backup queue)Changes for offline clients are queued until they reconnect.
• Save space: dedup, cold storage, version limitsIdentical blocks stored once; old versions moved to cold storage.
• Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
• Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.

7. Follow-up questions

1. Alice and Bob both edit the same document offline and reconnect a minute apart. What exactly happens?
2. A user uploads a 5 GB video over hotel Wi-Fi and the connection drops at 80%. What happens?

The design in a nutshell

• Clients → LB → API servers (metadata, auth) and block servers (chunk, compress, encrypt, delta upload) → cloud storage (+ cold storage).
• Metadata (users, devices, namespaces, files, file_versions, blocks) in a strongly consistent, replicated relational DB + cache invalidated on write.
• Notification service via long polling; offline backup queue; conflicts → first wins, conflict copy saved.
• Dedup identical blocks, cap versions, monitor sync latency and storage growth.

Related lessons: Block servers and delta sync · High consistency and the metadata database · Upload flow, download flow and notifications