Design Google Drive

The product lets a user add a file once and see it everywhere: upload and download, automatic sync across devices, a history of revisions, sharing with friends or colleagues, and a notification when a shared file is edited, deleted or shared. Real-time collaborative editing in the style of Google Docs is explicitly out of scope; this is about whole files that change occasionally, from small documents up to perhaps 10 GB.

The non-functional bar is unusually strict. Data loss is unacceptable, because users treat the service as the copy of record. Sync should feel fast, otherwise people stop trusting it. Bandwidth matters because many clients are on metered mobile links. And the system must scale to tens of millions of daily users and very large aggregate storage without the cost growing faster than the user base.

Assume 50 million signed-up users and 10 million daily actives, each given 10 GB of free space. The theoretical ceiling is 50M x 10 GB = 500 PB, which tells us immediately that storage cost, not compute, dominates the budget and that deduplication and cold tiers are first-class concerns rather than optimisations for later.

If each active user uploads two files a day of about 500 KB, that is 10M x 2 = 20M uploads per day. Dividing by 86,400 seconds gives roughly 230 uploads per second, and assuming peaks are twice the average, about 460 per second. Double-checking: 20,000,000 / 86,400 is a little over 231, so the order of magnitude holds. Write traffic is modest; the challenge is correctness and storage efficiency, not raw request rate.

Three API families cover the product. Uploads come in two flavours: a simple upload for small files sent in one request, and a resumable upload for large files, where the client first asks for a session URL, then streams data and can resume from the last acknowledged byte after a network drop. Downloads take a path or file ID. A revisions endpoint lists past versions with a limit so a heavily edited file does not return thousands of rows. Every call is authenticated and runs over HTTPS.

A single machine with a web server, a relational database and a local disk is a fine starting point, but it runs out of disk within weeks and is a single point of failure. The natural evolution is to move file bytes to object storage such as Amazon S3 with cross-region replication, so a whole-region outage does not lose data; put a load balancer in front of stateless web servers; move metadata to a replicated database; and keep the two stores separate so each can scale on its own axis.

Uploading a 2 GB video again because one byte changed would be wasteful, so files are cut into blocks of up to about 4 MB, each identified by a hash of its content. Block servers compress each block (the algorithm depends on file type), encrypt it, and store it in object storage under that hash. A file is then simply an ordered list of block hashes, and a new version is a new list.

This representation gives two big wins. Delta sync: when a file changes, the client recomputes block hashes and only uploads blocks whose hashes are new, so a small edit costs one block rather than the whole file. Deduplication: if two blocks anywhere in an account (or, with care, across accounts) share a hash, they are stored once. The split work can happen either on the client, saving upload bandwidth, or on block servers, which keeps clients simpler; most real systems push chunking to the client for exactly the bandwidth reason.

Metadata is the system's source of truth: which blocks make up which version of which file in whose namespace. If two devices could read different answers, a user might open a stale version or, worse, a sync client might delete a file it wrongly believes was removed. So the metadata store must be strongly consistent, and caches in front of it must be invalidated on write. A relational database gives ACID transactions for free, which is why it is the default choice here over an eventually consistent NoSQL store.

A workable schema has a user table; a device table holding a push ID per device; a namespace table representing a user's root directory; a file table with the latest metadata; a file_version table whose rows are immutable history; and a block table mapping each version to an ordered list of block hashes. Making version rows read-only protects revision history from accidental corruption by later writes.

An upload runs two requests in parallel. The first adds file metadata with status pending and tells the notification service a change is coming. The second sends the content to block servers, which chunk, compress, encrypt and write blocks to cloud storage. When storage confirms, a callback flips the status to uploaded and notifies every other device of the owner and of anyone the file is shared with.

Downloads are triggered by those notifications. An online client receives a change event and asks API servers for the new metadata, then fetches only the blocks it does not already have and reassembles the file. Notifications use long polling rather than WebSocket because traffic is one-way and infrequent: each client holds a request open, the server answers when something changes or the timeout fires, and the client immediately reconnects. Changes for offline clients go into an offline backup queue so they are delivered on reconnect.

With hundreds of petabytes in play, every percent of storage saved is real money. Deduplicate identical blocks at the account level. Cap the number of revisions kept and give recent versions more weight, because a frequently edited file could otherwise accumulate thousands of near-identical versions. Move data that has not been touched for months to a cold storage tier such as S3 Glacier, which is far cheaper per gigabyte but slower to read.

When two users or two devices edit the same file concurrently, the rule is simple: the first version processed wins, and the later one is preserved as a conflict copy alongside the original. The losing user sees both and merges by hand. Automatic merging of arbitrary binary formats is impossible, and silently discarding work would break the durability promise, so presenting both copies is the honest trade-off.

Each component needs a story for its failure. A load balancer pair uses heartbeats so a secondary takes over. Block and API servers are stateless, so others pick up the traffic, although an in-flight upload may need to resume. Object storage is replicated across regions. The metadata database uses primary-replica replication with promotion of a replica if the primary dies. Notification servers hold many long-lived connections; when one fails, clients reconnect to another, which is slow if millions do so at once, so reconnection must be spread out.

The interview takeaway is the separation of concerns: bytes go to cheap, durable object storage in content-addressed blocks; meaning lives in a small, strongly consistent metadata database; and freshness is delivered by a lightweight push channel. A good extension to discuss is uploading directly from the client to object storage with signed URLs, which removes block servers from the data path but moves chunking, compression and encryption logic onto every client platform.