Design Google Drive

01The design, in the six-step framework

1. Requirements

Functional

• Upload, download and delete files and folders from a browser, a desktop sync client and a phone.
• Keep every version of a file for 30 days and let a user restore one.
• Share a file or folder with specific people (view or edit) and with a link.
• Sync a folder across a user's devices so an edit on one appears on the others within seconds.
• Out of scope: real-time co-editing inside a document (that is Google Docs), search inside file contents, payments for storage.

Non-functional

• 1 billion users, 100 million active per day, average 20 GB stored per user.
• Durability first: a stored byte is never lost (eleven nines). Availability 99.99 percent for reads.
• Upload of a 1 GB file resumes after a dropped connection instead of restarting.
• Metadata operations (list a folder, rename) under 100 ms at p99; sync propagation under 10 s.
• Consistency: a user always sees their own latest write; two devices editing the same file never silently lose one edit.

2. Core entities

• User: id, email, storage quota and usage.
• File: id, owner, parent folder, name, size, current version id, created and modified times, deleted flag.
• Version: file id, version number, list of chunk hashes in order, size, author, timestamp.
• Chunk: content hash (SHA-256), size, storage location, reference count.
• Share: file or folder id, grantee (user or link), role (viewer or editor), expiry.
• Device: device id, user, last synced change cursor.

3. API

• POST /uploads → start an upload: request has name, parent, size and the list of chunk hashes; response says which chunks the server already has and gives upload URLs for the rest.
• PUT /chunks/{hash} → upload one chunk body (called by the client for each missing chunk, in parallel).
• POST /uploads/{id}/commit → all chunks are present; create the new version atomically; returns the new file version.
• GET /files/{id}?version= → metadata plus signed download URLs for the chunks (or a single CDN URL for small files).
• GET /changes?cursor= → every change to the user's files since the cursor, in order; used by the sync client.
• POST /files/{id}/shares → grant a role to a user or create a link.

4. High-level design

One upload of a 1 GB file, end to end:

1. The client cuts the file into 4 MB chunks and hashes each one (256 hashes), then calls POST /uploads with the hash list.
2. The metadata service checks which hashes already exist in the chunk table. For a file the user already had, or a popular installer, most of them do. It returns only the missing hashes.
3. The client uploads the missing chunks in parallel to the upload service, which writes each straight into object storage under its hash. A dropped connection costs at most one 4 MB chunk.
4. commit writes one row in the version table and updates the file row, in a single transaction on the user's shard.
5. The same transaction appends a change event to the change log. The notifier fans it out to the user's other devices, which call GET /changes and download the new chunks, usually through the CDN.

5. Deep dives

How do we make a 1 GB upload survive a flaky phone connection?

The simple answer is one HTTP PUT of the whole file, and it fails at the stated scale: a 1 percent per-minute drop rate on mobile means most 1 GB uploads never finish. Chunking fixes it. Fixed-size 4 MB chunks are the easy choice; content-defined chunking (cut where a rolling hash hits a pattern) is better for files that are edited in the middle, because an insert shifts the fixed boundaries and makes every later chunk look new. Drive-like products use content-defined chunks for exactly that reason. Each chunk upload is idempotent (the key is the hash), so a retry after a timeout cannot duplicate data, and commit only succeeds when every hash in the manifest is present.

Choice: content-defined chunks with a 4 MB target, because most storage in Drive is versions of files people keep editing.

Where does the metadata live, and how do we shard it?

Putting file metadata in the same store as the bytes is the classic mistake: listing a folder would mean scanning object storage. Keep metadata and content apart: a relational store for files, versions and shares, object storage for chunks. Shard the relational store by owner id, because almost every query (list my folder, my recent files, my quota) is scoped to one user and lands on one shard. Shared files break that rule: a file shared with you still lives on the owner's shard. Store a small pointer row on the grantee's shard (file id, owner shard) so "shared with me" is one local read followed by point lookups. The hard question an interviewer asks next is a user with a million files; a per-user shard can hold it, and folder listings are paginated with cursors so no single call returns a million rows.

Two devices edit the same file offline. Which one wins?

Neither should win silently. Every version carries the parent version it was based on. When device B commits version 5 based on version 3 but the server is already at 4 (from device A), the commit is rejected with a conflict. The client then creates a "conflicted copy" next to the original and uploads it as a new file, which is what the real product does. This is optimistic concurrency, and it works because commit runs as one transaction on one shard and compares the expected parent version. For folders the same trick applies to renames and moves. See sync and conflict resolution for the general pattern; true merging of edits belongs to Docs, not Drive.

How does a change on one device reach the others in seconds without a million clients polling?

Polling GET /changes every 5 seconds from 100 million devices is 20 million requests a second for almost no news. Instead the commit publishes a change event to a per-user topic on the change log; a long-lived connection (WebSocket, or a push notification on mobile) tells the device "you have changes", and only then does it call GET /changes?cursor=. The cursor is the position in the user's change log, so a device that was off for a week catches up in order and never misses an event. Downloads go through the CDN keyed by chunk hash; a chunk is immutable, so it can be cached forever and shared between users who hold the same bytes.

6. What a strong answer sounds like

• Say the numbers: 20 EB logical, about 50,000 writes/s at peak, 500 TB of metadata, and that dedup is why the physical number is half the logical one.
• Separate the two planes clearly: metadata on sharded relational storage, bytes on object storage, and explain why listing a folder must never touch the blob store.
• Describe chunking as the single idea that gives you resumable uploads, dedup and cheap versions at once.
• State the conflict rule (parent version check, conflicted copy) before the interviewer asks; it is the most common follow-up.
• Expect follow-ups on quota enforcement, deleting a chunk that other files reference (reference counts and a delayed garbage collector), and permission checks on a shared folder tree.
• Common mistake: proposing a last-writer-wins merge for file bytes, which loses someone's work.

02Where this question was reported

• IGotAnOffer · SWE list 'Design Google Drive'; worked answer notes the file-sharing question 'would likely be presented as Design Google Drive' at Google
• IGotAnOffer · 'write-heavy file-storage service like Google Drive'
• Exponent · 'Design Google Drive: distributed file storage with versioning, sharing, and sync'
• interviewkickstart.com · 'global file storage or a sharing service'
• interviewkickstart.com · 'your version of Google Drive'
• DesignGurus · Versioning, ACLs, sharing
• DesignGurus · Common at Google and Amazon
• DesignGurus · 'File-sharing Service Like Google Drive or Dropbox'
• System Design Handbook · 'Google Drive or a Cloud Storage System'
• System Design Handbook · Listed
• PracHub · PM: 'Real-time sync mechanics and storage data model for Google Docs and Drive'
• DesignGurus · Listed as commonly asked at Google (as GFS-style distributed file system / cloud storage).