Google Drive

Assume 1B registered users, 300M daily active users, 20B file and folder metadata nodes, 1B metadata mutations per day, and 30B metadata reads per day from web, mobile, desktop sync, and collaboration surfaces.

Assume 50M new file versions per day with an average logical size of 8 MB. Deduplication and compression reduce physical storage by about 35 percent. Assume 1B file downloads per day with an average served size of 3 MB, most of which should come from CDN or regional blob serving. Peak traffic is 10x average for metadata and 8x average for content transfer.

• Metadata records: 20B nodes times 2 KB is 40 TB raw. With secondary indexes, ACL-derived fields, change history, and 3x to 4x replication, plan for roughly 180 to 240 TB.
• Metadata reads: 30B reads per day divided by 86,400 seconds is about 347,000 reads per second on average. A 10x peak means about 3.5M reads per second.
• Metadata writes: 1B mutations per day divided by 86,400 seconds is about 11,600 writes per second on average. A 10x peak means about 116,000 writes per second.
• Content ingest: 50M new versions per day times 8 MB is 400M MB per day, or about 400 TB logical. With 35 percent savings, physical ingest is about 260 TB per day before replication.
• Download bandwidth: 1B downloads per day times 3 MB is 3B MB per day, about 3 PB per day. Dividing by 86,400 seconds gives about 35 GB per second average. An 8x peak is about 280 GB per second, mostly handled by CDN and regional blob stores.
• Collaboration: 1M concurrent editors at one operation every five seconds produces 200,000 operations per second. The operations are small, but ordering, fanout, and persistence dominate.
• Change feed: if each metadata mutation and committed collaboration batch emits one event, the feed must absorb more than 1B events per day before retries and backfills.

• drive_nodes.node_id is the primary lookup key for open, update, move, and permission checks.
• drive_nodes.parent_id, name supports folder listing and uniqueness rules inside one folder.
• drive_nodes.owner_id, modified_at supports recent files and owner-scoped sync.
• permissions.resource_node_id supports loading explicit grants for a file or folder.
• permissions.principal_id, role supports shared-with-me and enterprise access reviews.
• file_versions.node_id, created_at supports version history and restore.
• change_log.shard_id, sequence_number supports cursor-based sync with ordered pagination.
• Search should use a separate inverted index because metadata stores are not optimized for full-text ranking.

Each node belongs to an owner or shared drive and usually has one parent. Folder inheritance is logical: descendants do not need a copied ACL row for every inherited grant. Permission evaluation combines explicit grants, inherited ancestors, organization policy, and link policy. File versions reference immutable blob manifests, and change_log events reference nodes so clients can sync without scanning the metadata tables.

A production design can use a globally distributed SQL database such as Spanner or FoundationDB for metadata transactions, because moves, shares, and version commits need conditional updates and consistent indexes. Blob chunks belong in object storage such as Colossus, S3, Azure Blob Storage, or a custom distributed file system with replication and erasure coding.

The change feed can live in Bigtable, Kafka, Pulsar, or a log-structured store partitioned by owner or shared drive. The search index should be external, such as Elasticsearch, OpenSearch, Solr, or a custom inverted-index service. ACL-derived fields may be denormalized into the search index, but every content access must still be authorized against a fresh enough permission decision.

A naive design stores full paths such as /team/plans/q3.docx in every descendant. Moving a large folder would require rewriting all child paths and invalidating huge parts of the index. The better design uses stable node IDs with parent_id references. A move updates only the moved folder parent pointer and name, then emits one change for the moved subtree root.

Folder listing is still hard because large shared folders can have millions of children and many concurrent viewers. Use parent_id plus sorted pagination indexes, cap page sizes, and treat extremely large folders as a special scale case with materialized child lists or partitioned listing tables.

Name uniqueness is a product decision. If names must be unique within a folder, enforce uniqueness with a conditional write on parent_id and normalized name. If duplicates are allowed, folder listing can be simpler, but the UI and sync clients need stable IDs to distinguish same-name files.

Permissions are the distinguishing part of Drive compared with a simple object store. A file may be visible because of direct user access, a group grant, a domain grant, a public link, ownership, shared drive membership, or inherited folder ACLs. The Permission Service should evaluate these sources in a predictable order and return the effective role.

Do not copy every folder ACL to every descendant for normal inheritance. That makes sharing a folder with a million files too expensive and makes revocation dangerous. Instead, store explicit grants at the folder and evaluate ancestors or maintain compact materialized ACL summaries with an acl_version. Caches are allowed, but the version must let services reject stale decisions.

Revocation is more sensitive than granting. If a user removes access, cached signed URLs, search results, collaboration sessions, and sync clients must stop exposing content within a bounded window. Short-lived download URLs, ACL-versioned cache keys, and high-priority invalidation events are essential.

Binary file content should be stored as immutable chunks and manifests. Chunking enables resumable upload, parallel download, deduplication, and partial retry. Content-addressed chunks let identical bytes be stored once, while manifests define each file version as an ordered list of chunks.

Deduplication has tradeoffs. Global dedup saves the most storage but can leak information if an attacker can infer whether a chunk already exists. Safer designs deduplicate within a tenant or use server-side checks that do not reveal cross-tenant existence. Compression and thumbnail extraction should run asynchronously.

Quota should be charged at version commit time using a reservation model. Reserve expected bytes when upload starts, adjust charged bytes after deduplication, and release reservations on abort. The quota ledger can be eventually consistent for display, but enforcement needs enough atomicity to stop unlimited overage.

Native documents are not just files with frequent saves. Multiple users edit paragraphs, tables, comments, and formatting at the same time. The service receives operations based on different revisions and must produce a convergent document state for every participant.

Operational Transform keeps a server-ordered log and transforms incoming operations against concurrent committed operations. It gives centralized control and mature semantics, but transform functions are complex for rich document structures. CRDTs allow more decentralized merging and offline edits, but can add metadata overhead and need careful compaction.

In an interview, choose a collaboration model and explain why. For a Google Drive style product, a server-mediated OT or server-coordinated CRDT design is practical: active sessions are routed to a collaboration shard, operations are persisted before acknowledgement, snapshots bound replay cost, and offline clients reconcile local edits through operation replay or conflict copies.

Sync clients cannot scan all files repeatedly. They need a durable change feed scoped to the user or shared drive. Each event has an ordered sequence, affected node, change type, tombstone marker, and enough metadata for the client to update local state or request details.

Clients go offline, miss events, and reconnect with old cursors. The service should retain change history for a defined window, then return a cursor expired response that forces a full or scoped resync. Events should be idempotent because clients may receive duplicates after retries.

Conflicts happen when two offline clients edit or move the same binary file. Metadata conflicts can use last-writer-wins only for safe fields, but content conflicts often require creating a conflict copy or a separate version for user resolution. Native documents can merge operations through the collaboration engine.

Search uses derived data: file names, owners, MIME types, timestamps, OCR text, extracted document text, labels, comments, and thumbnails. Indexers consume the change feed and update an inverted index asynchronously, so search freshness is eventually consistent.

Permission filtering must be designed carefully. One option stores ACL-derived visibility tokens in the index and filters candidate documents by the caller's tokens. That is fast but must react to revocation and group changes. Another option performs post-filter authorization against the Permission Service, which is safer but can increase latency and reduce recall if many candidates are filtered.

A balanced design uses visibility tokens for broad filtering, ACL versions for freshness, and final authorization for sensitive downloads. Search can lag after upload, but it must not reveal a private file after access is removed.

Alternative one is an object-store-first design: put every file in object storage and store minimal metadata in a database. It is simple for personal backup but weak for folder hierarchy, sharing inheritance, search, and collaboration.

Alternative two is a fully path-based file system namespace. It is intuitive but expensive for moves and rename operations across large subtrees. Stable IDs with parent pointers scale better.

Alternative three is a centralized collaboration document store for all content. It works for native docs but is inefficient for large binary files, videos, archives, and offline desktop sync.

Do not design Google Drive when the requirement is only archival object storage, a CDN-backed static file host, or a database for structured records. Drive is appropriate when users need human-facing hierarchy, sharing, collaboration, sync, versioning, search, and governance over files.