Design Google Drive

Google Drive: file storage and synchronization service. Access files from any device; share with others.

Step 1 of 4: Understand the problem and establish design scope #

Goal: lock in requirements and scale numbers.

Requirements (in-scope):

1. Add files (drag & drop), download files
2. Sync files across multiple devices
3. See file revisions (version history)
4. Share files with friends/family/coworkers
5. Notifications on file edit, delete, share

Out of scope: Google Doc collaborative editing.

Non-functional requirements:

1. Reliability: data loss is unacceptable
2. Fast sync speed
3. Bandwidth usage: minimize, especially on mobile data
4. Scalability, high availability

Back of the envelope estimation:

1. 50M signed up users, 10M DAU
2. 10 GB free space per user → 500 PB total allocated
3. 2 file uploads/day, avg 500 KB per file
4. 1:1 read:write ratio
5. Upload QPS: 10M × 2 / 86400 = ~240 QPS
6. Peak QPS: 480

Step 2 of 4: Propose high-level design and get buy-in #

Goal: start single-server, then scale out: shard by user, S3 for files, blocks for delta sync.

Starting point: single server #

Apache web server, MySQL, /drive/ root directory with per-user namespaces. Uniquely identify files by joining namespace + relative path.

APIs #

1. Upload: simple upload (small files) or resumable upload (large files, network interruption). Steps: request resumable URL → upload data + monitor → resume if interrupted
   • POST https://api.example.com/files/upload?uploadType=resumable
2. Download: GET https://api.example.com/files/download, param path
3. Get file revisions: GET https://api.example.com/files/list_revisions, params path, limit

All APIs require HTTPS + authentication.

Scaling out #

1. Shard by user_id across multiple storage servers
2. Move files to Amazon S3: same-region + cross-region replication for durability

Further improvements:

1. Add a load balancer + more web servers
2. Move the metadata DB out of the server → replication + sharding
3. S3 for file storage with multi-region replication

Sync conflicts #

First-write-wins strategy: the first version processed succeeds; the later version receives a conflict. User is presented with both copies: can merge or override.

High-level design #

Components:

1. Block servers: split files into blocks (max 4MB per Dropbox reference), compress, encrypt, upload to cloud. Enable delta sync (only changed blocks transferred)
2. Cloud storage (S3): stores file blocks
3. Cold storage (S3 Glacier): inactive data
4. Load balancer: distributes requests to API servers
5. API servers: authentication, user profile, file metadata management
6. Metadata database: user, file, block, version metadata (files themselves in cloud)
7. Metadata cache: fast retrieval of frequently accessed metadata
8. Notification service: pub/sub; notifies clients when files are added/edited/removed
9. Offline backup queue: stores changes for offline clients to sync when they reconnect

Step 3 of 4: Design deep dive #

Goal: block servers, strong consistency, flows, notifications, storage savings.

Block servers #

Optimizations to reduce network traffic:

1. Delta sync: only sync modified blocks (rsync algorithm)
2. Compression: gzip/bzip2 for text; different algorithms for images/video

Flow for a new file:

Split → compress each block → encrypt → upload to cloud storage.

Delta sync:

Only changed blocks (e.g. block 2 and block 5) are uploaded.

High consistency requirement #

System requires strong consistency: files must not appear differently to different clients simultaneously.

1. Memory caches default to eventual consistency → must enforce:
   • Cache replicas consistent with master
   • Cache invalidation on DB write
2. Relational database chosen over NoSQL because ACID is natively supported (NoSQL requires programmatic ACID in sync logic)

Metadata database #

Schema (simplified):

1. User: username, email, profile photo
2. Device: device info, push_id for mobile notifications (one user → many devices)
3. Namespace: root directory of a user
4. File: latest file information
5. File_version: version history; rows are read-only for revision integrity
6. Block: file block info; any version reconstructed by joining blocks in order

Upload flow #

Two parallel requests from client 1:

Add file metadata:

1. Client 1 sends metadata → 2. Store in metadata DB, status = "pending" → 3. Notify notification service → 4. Notification service informs client 2

Upload files to cloud storage:

1. Client 1 uploads to block servers → 2. Block servers chunk, compress, encrypt, upload to S3 → 3. S3 triggers upload completion callback to API servers → 4. File status → "uploaded" in metadata DB → 5. Notification service notified → 6. Client 2 informed

Download flow #

Client learns of changes via:

1. Online: notification service informs
2. Offline: changes held in the offline backup queue; synced on reconnect

Flow:

1. Notification service informs client 2 → 2. Client 2 requests metadata → 3. API servers fetch from metadata DB → 4–5. Metadata returned → 6. Client 2 requests blocks from block servers → 7. Block servers fetch from cloud storage → 8–9. Blocks returned, client reconstructs file

Notification service #

Options: long polling vs WebSocket.

Chose long polling because:

1. Communication is one-directional (server → client about file changes)
2. WebSocket is better for real-time bidirectional (chat apps); Google Drive notifications are infrequent

Client holds a long poll connection. File change detected → connection closed → client connects to metadata server to download latest changes → immediately sends a new long poll request.

Save storage space #

1. De-duplicate data blocks: identical hash → same block; eliminate redundant blocks
2. Intelligent backup strategy: limit number of versions; keep only valuable versions (weight recent versions higher)
3. Cold storage: move inactive data (months/years) to S3 Glacier: much cheaper than S3

Failure handling #

Step 4 of 4: Wrap up #

Alternative design: upload directly to cloud from client:

1. Pro: faster (one transfer vs. client → block server → cloud)
2. Cons: chunking/compression/encryption logic duplicated across platforms (iOS, Android, Web); client-side encryption less secure

Additional evolution: move online/offline logic to a separate presence service (reusable by other services).