Design Google Drive

Files are split into fixed-size 4MB blocks on the client. Each block is hashed with SHA-256 — this hash is the block's globally unique identifier. When a file is modified, only the changed blocks have new hashes. The Block Server checks which block hashes already exist in S3. Only NEW blocks (never-seen-before hashes) are uploaded. This is content-addressed storage — identical blocks across different files share the same S3 object.

The sync process on each file save: (1) Client computes SHA-256 for each 4MB block of the modified file, (2) Compares against stored block hashes from last sync (saved locally), (3) Sends only the list of block hashes to the Metadata Service, (4) Metadata Service returns which hashes are NOT in S3 (new blocks that need uploading), (5) Client uploads ONLY those new blocks. For a 1GB file where only one paragraph changed: only 4MB is uploaded instead of 1GB. This is the core bandwidth savings.

File metadata — file name, owner, permissions, parent folder, list of block hashes in order, version history, created/modified timestamps — is stored in MySQL with full ACID transactions. Why SQL (not NoSQL)? Because file system operations require strong consistency: moving a file, sharing permissions, and version creation must be atomic. A partial metadata update (file moved but permissions not updated) would be catastrophic. MySQL is sharded by user_id.

When User A modifies a file shared with User B (and B has Drive open on their laptop), B's Drive client needs to know immediately to download the new blocks. The Notification Service maintains a WebSocket/SSE connection to each active Drive client. When the Metadata DB is updated (new file version), a notification event is published to Kafka, consumed by the Notification Service, and pushed to all subscribed devices of affected users.

Every time a file is saved, a new version record is created in MySQL linking to the current list of block hashes. Old versions are NOT deleted immediately — they're retained for 30 days (or forever for paid plans). Because blocks are content-addressed and shared across versions, version history doesn't multiply storage: if a 1GB file has 100 versions and only 1 block changed each time, storage is 1GB + 100 × 4MB = ~1.4GB (not 100GB).

When two devices modify the same file simultaneously (Device A offline, Device B online), both have valid changes. Google Drive uses a last-writer-wins with conflict copy strategy: (1) First modification to sync wins and becomes the current version, (2) The losing modification is saved as a separate "conflicted copy" file (e.g., "file (conflicted copy 2024-01-15).docx"), (3) User sees both files and must manually merge. For Google Docs (collaborative editing), Operational Transform (OT) or CRDT enables real-time concurrent editing without conflicts.