How Would You Design Google Drive?
Learn how to design Google Drive: real-time collaborative editing with OT/CRDTs, permissions graphs, and file sync architecture.
Expected Interview Answer
Designing Google Drive builds on a chunked-storage-and-sync foundation like Dropbox but adds a real-time collaborative editing layer, where concurrent edits to the same document are merged using operational transformation or CRDTs instead of file-level conflicted copies, plus a fine-grained sharing/permissions model layered on top of file metadata.
File storage and sync (chunking, deduplication, blob storage, metadata versioning) works much like any cloud storage system, but the key differentiator is live collaborative editing on documents, spreadsheets, and slides: each keystroke is sent as a small operation to a central server, which applies operational transformation or a CRDT-based merge algorithm to reconcile concurrent edits from multiple users and broadcast the resolved state back to every connected client in real time. Access control is modeled as a permissions graph per file/folder (owner, editor, commenter, viewer, plus link-sharing scopes), checked on every read/write and propagated efficiently down folder hierarchies. Search needs to index not just filenames but full document content, requiring a separate indexing pipeline that consumes change events. Because many users can be viewing/editing the same file concurrently, presence (who is currently in the document) and cursor position are also synced through a lightweight real-time channel separate from the durable storage path.
- Operational transformation/CRDTs allow true real-time multi-user editing without lock contention
- A separate permissions graph lets sharing scale independently from raw file storage
- Decoupled full-text search indexing keeps document content searchable without slowing writes
- Real-time presence/cursor sync improves collaboration UX without touching the durable storage path
AI Mentor Explanation
Designing Google Drive is like a live scoreboard operator who accepts small, atomic updates from multiple assistant scorers simultaneously — a run here, a wicket there — merging each incoming update into the master scoreboard state instead of requiring one scorer to finish before another can act. The system reconciles near-simultaneous updates (two assistants logging different balls in the same over) using a defined ordering rule so the board never shows contradictory information. Meanwhile, only accredited scorers get write access while spectators get read-only views, exactly mirroring a permissions graph. That real-time, multi-writer reconciliation with tiered access is precisely what collaborative document editing requires.
Step-by-Step Explanation
Step 1
Store and version files like generic cloud storage
Chunk, deduplicate, and store blobs, with a metadata service tracking folder structure and version history.
Step 2
Stream fine-grained edit operations
Each keystroke or cell edit is sent as a small operation to a central server rather than the whole file being re-uploaded.
Step 3
Reconcile concurrent edits in real time
Operational transformation or CRDT merge logic resolves concurrent operations and broadcasts the reconciled state to all connected clients.
Step 4
Enforce a layered permissions graph
Every read/write checks owner/editor/commenter/viewer scopes, propagated efficiently down shared folder hierarchies.
What Interviewer Expects
- Distinguishes real-time collaborative editing (OT/CRDT) from simple file-level sync
- Explains why file-level conflicted copies are insufficient for documents edited concurrently by many users
- Describes a permissions/sharing model as a graph checked on every access, not just a flag on the file
- Mentions decoupled full-text search indexing driven by change events
Common Mistakes
- Treating Google Drive as identical to Dropbox and ignoring live collaborative editing entirely
- Proposing pessimistic locking (one editor at a time) instead of OT/CRDT-based concurrent merging
- Modeling permissions as a single boolean flag instead of a graph with roles and inheritance
- Forgetting that document content search requires a separate indexing pipeline beyond filename search
Best Answer (HR Friendly)
“I would build the storage and sync layer the same way any cloud drive works, but the key difference for Google Drive is that multiple people can type into the same document at once. So every keystroke gets sent as a tiny change to a central server that merges everyone's edits together in real time, instead of making people wait their turn or overwrite each other. On top of that, sharing permissions decide who can edit, comment, or just view each file or folder.”
Code Example
function applyRemoteOp(localDoc, remoteOp, pendingLocalOps) {
// Transform the incoming remote operation against any local
// operations that have not yet been acknowledged by the server,
// so it applies correctly to the current local document state.
let transformedOp = remoteOp
for (const localOp of pendingLocalOps) {
transformedOp = transform(transformedOp, localOp)
}
localDoc = apply(localDoc, transformedOp)
broadcastToOtherClients(transformedOp)
return localDoc
}
function checkPermission(userId, fileId, requiredRole) {
const grant = permissionsGraph.resolve(userId, fileId) // owner/editor/commenter/viewer
const roleRank = { viewer: 0, commenter: 1, editor: 2, owner: 3 }
return roleRank[grant.role] >= roleRank[requiredRole]
}Follow-up Questions
- What is the difference between operational transformation and CRDTs for collaborative editing?
- How would you design the permissions graph so shared-folder access propagates efficiently to thousands of nested files?
- How would full-text search across document content be kept up to date as documents are edited live?
- How would you handle a client that reconnects after being offline for hours while a document changed extensively?
MCQ Practice
1. Why is file-level conflict resolution (like a conflicted copy) insufficient for Google Docs-style editing?
Concurrent, character-level edits from many users require operational transformation or CRDT-based merging, not coarse file-level conflict copies.
2. What is the purpose of operational transformation (OT) in collaborative editing?
OT (and CRDTs) resolve concurrent edits from multiple clients into a consistent, converged document state in real time.
3. Why should permissions be modeled as a graph rather than a single flag on a file?
A permissions graph supports role-based access and inheritance through folder structures, which a single boolean cannot express.
Flash Cards
What powers real-time multi-user document editing? — Operational transformation or CRDT-based merging of small, concurrent edit operations.
Why not use file-level conflicted copies for Google Docs? — Many users edit the same document concurrently, requiring fine-grained real-time reconciliation instead.
How is sharing modeled? — As a permissions graph with roles (owner/editor/commenter/viewer) that propagate down folder hierarchies.
Why is document search a separate pipeline? — Full-text content indexing must react to live edits without slowing down the write path.