Design Google Drive/Dropbox

Functional Requirements

• Add Files

• Download files

• Sync files across multiple devices

• See file revisions

• Share files with friends and family

• Send notification when file is edited, deleted, or shared with you

Non-functional

Available

Scalable

Secure

ACID-ity

Reliable

BOE

50 million signed up, 10 million DAU. Users get 10 GB

Assume users upload 2 files/day, average file size is 500KB

1:1 read write ratio

Total space is 50 million * 10 GB = 500 PB

QPS for upload API: 10 million * 2 / 10^5 is exactly 240 when not rounding secs in day

High Level Design

Block servers
Cloud Storage
Cold Storage
Notification Service

MetaData DB
Offline Backup Queue

Block Server

Files split into smaller blocks, each with unique hash value. Store metadata in our metadata db. Blocks stored in S3. Joined to create file. If updated, just do delta of old block. compression for space optimization.

Consistency Requirements

HIGH consistency. Memory cache adopts eventual consistency model. To enforce this strong consistency, INVALIDATE CACHE ON WRITE. Diagram in upload flow

must use relational DB for ACID-ity. Must be ACID for strong consistency.

To prevent sync conflicts, use versioning. Can do timestamp or version number- do version number. Time can be messed up depending on server. Version number uses first to get that version number if conflict occurs.

Uploading flow

User A wants to upload file

1. send request to add metadata of new file. Stores in metadata DB, then notification service notifies relevant clients

2. client A uploads file to block servers. Block servers take chunk, compress and encrypt, then upload to cloud. Cloud storage triggers completion callback

3. File status changed in metadata db. notify the notification service to tell relevant clients.

   
   

Download Flow

If client 2 online when file is changed by another user, notification service will inform client that they need to pull data. Otherwise, data will be saved to the cache and when client is online again, they will pull.

Notification Service design

Websocket vs long polling. Use long polling, not bi-directional. Websocket better for chat apps. (or uber!) Dropbox uses long polling. When user closes long poll to download data, it reestablishes connection.

Storage space vs versioning (storage space optimizing)

to save space:

1. only keep certain number of versions

2. if old versions never used, delete?

3. move infrequently accessed to cold storage.

4. de duplicate if same hash.

Random Extras

• Duplicate block servers in case one fails

• duplicate S3 buckets in different regions

• notification service failure- reconnecting all clients from disconnected server. May be very slow, but necessary. Need to have backups

• Load balancers keep heartbeats. If primary fails, secondary takes traffic

• Offline backup queues are replicated multiple times. If one fails, user may need to re-subscribe to backup queue