Design Cloud File Storage and Sync

Prompt

"Design Google Drive: files live in the cloud, a desktop client keeps a local folder in sync across all of a user's devices, and files can be shared with other users."

Clarifying questions

• Which clients? Desktop sync client (the hard one), plus web and mobile that fetch on demand.
• File sizes? Anything from a few KB to tens of GB. Typical is under 1 MB; large media files exist but are rare.
• Do we need file versioning? Yes, keep a bounded history (30 days) so users can restore.
• What happens on concurrent edits to one file from two devices? No merging of binary content. Detect the conflict and keep both copies; Docs-style collaborative editing is a different system.
• Offline support? Yes, the desktop client must work offline and reconcile when back online.
• Sharing semantics? Share a file or folder with specific users with view or edit permission. Public links are a follow-up.
• Scale? Hundreds of millions of users, several devices each.
• Consistency expectations? A change on one device should appear on the user's other devices within seconds when online; strict ordering across different files is not required.

Requirements

Functional

• Upload, download, delete, rename, move files and folders.
• Keep a local folder in sync with the cloud across devices, including offline changes.
• Version history with restore.
• Share with other users and enforce permissions.

Non-functional

• Durability is paramount: user data must never be lost, including across region failures.
• Sync should be bandwidth-efficient: editing a small part of a large file should not re-upload the whole file.
• Metadata operations should feel instant; content transfer can be background.
• Correctness under concurrent edits: never silently overwrite one user's work with another's.

Back-of-envelope

• 500M users, 2 devices each on average → 1B sync clients, of which maybe 10% are online and active at any time → 100M live connections. Connection fan-out is a first-order scaling problem.
• Files: assume 300 files per user average → 150B file records. At 500 B of metadata each that is 75 TB of metadata. Sharded metadata store, not a single database.
• Storage: 500M users × 10 GB average used → 5 EB (5,000 PB) of content. Deduplication and compression help but the order of magnitude stays. Object storage with erasure coding, not replicas, to control cost.
• Change rate: assume each active user makes 20 file changes/day. 100M active/day × 20 = 2B changes/day ≈ 23,000 changes/s average, 100,000/s peak. Each change generates a notification fan-out to that user's other devices and to sharers.
• Upload bandwidth: if the average change moves 500 KB after chunk-level dedup, 23,000 × 500 KB ≈ 11.5 GB/s inbound average. Significant but fine for an object storage front end spread across regions.
• Chunk store: with 4 MB chunks, a 5 EB corpus is about 1.25 trillion chunks. The chunk index (hash → location, ~64 B per entry) is 80 TB. Big, but sharded by hash prefix it is a well-understood key-value problem.