Design Google Docs

01The design, in the six-step framework

1. Requirements

Functional

• Several people edit the same document at the same time and each sees the others' changes within a second, with cursors.
• Every edit is kept: version history, named versions, and restore.
• Editing works offline; changes merge when the device reconnects.
• Sharing with view, comment and edit permissions, by person or link.
• Out of scope: spreadsheets and slides, rich embeds, real-time voice.

Non-functional

• Scale: 1 billion documents, 50 million daily active editors, up to 100 simultaneous editors on one document (a classroom), 500 on a rare viral doc.
• Latency: a keystroke appears on collaborators' screens in under 500 ms p95 within a region, under 1.5 s across regions.
• Consistency: all collaborators converge to the same text; no edit is ever lost, including offline ones.
• Durability: an accepted edit survives any single machine failure.
• Availability: 99.99 percent for editing an open document.

2. Core entities

• Document: doc id, owner, title, current revision number, ACL, created at.
• Operation: doc id, revision, author, timestamp, the change (insert text at position, delete range, apply style), client id and client sequence number.
• Snapshot: doc id, revision, full content; taken every N operations so a load never replays the whole log.
• Session: doc id, user, connection id, cursor position, last acknowledged revision.
• Comment: doc id, anchor range, thread, resolved flag.

3. API

• GET /docs/{id} returns the latest snapshot and the operations after it, plus the revision number the client must start from.
• WS /docs/{id}/stream: the client sends operations tagged with the revision they were based on and a client sequence number; the server broadcasts committed operations with their assigned revision. This is the hot path.
• GET /docs/{id}/revisions?from=&to= for history; POST /docs/{id}/restore with a revision.
• PUT /docs/{id}/acl for sharing.

4. High-level design

1. The client opens the document: it loads the latest snapshot plus the tail of operations and starts a websocket.
2. Each keystroke becomes an operation applied locally at once (the UI never waits), then sent with the base revision.
3. The gateway forwards it to the single owner node for that document, found through the router. The owner node holds the live document in memory and is the one place where operations are ordered.
4. The owner transforms the incoming operation against any operations committed since the client's base revision (operational transformation), assigns the next revision number, appends it to the replicated log, and only then broadcasts it to every session.
5. A snapshot worker folds the log into a fresh snapshot every few hundred operations so a cold load is one snapshot plus a short tail.

5. Deep dives

How do concurrent edits converge: OT or CRDT?

Two editors insert at the same position at the same time. With operational transformation, the server is the arbiter: it accepts operations in arrival order, and when an operation was based on an older revision, it transforms it against the operations it missed so the intent is preserved (an insert at position 5 becomes an insert at 7 if two characters were inserted before it). Clients do the mirror transform for operations they receive while they have unacknowledged edits in flight. The invariant is that every client applies the same operations in the same final order, so all converge. A CRDT instead gives every character a unique, totally ordered identifier so inserts commute without a central arbiter, at the cost of larger documents and tombstones for deletions. For a server-mediated product with history and permissions, OT with a single owner per document is simpler and is what the real product does; say that CRDTs win when there is no server to order operations, such as peer-to-peer or heavily offline use.

What does the single owner node mean for scale and failure?

Ordering needs one place per document, not one place for all documents. Documents are sharded across thousands of owner nodes by doc id; one node holds tens of thousands of idle documents and a few hundred hot ones. The hot 500-editor document is still fine: 500 editors at 0.3 ops a second is 150 ops a second, trivial to serialise, and the broadcast fan-out of 150 × 500 = 75,000 messages a second is spread over the gateway tier. When an owner node dies, the router reassigns its documents; a new owner rebuilds state from the snapshot and the replicated log, and clients reconnect and resend any unacknowledged operations with their client sequence numbers, which makes the resend idempotent. Nothing is lost because an operation is acknowledged only after the log append is replicated.

How does offline editing merge?

Offline, the client keeps applying operations locally and queues them with the last revision it saw. On reconnect it sends the queue; the owner transforms each operation against everything committed meanwhile, possibly hundreds of operations. The transform is linear in the number of missed operations per queued operation, so a long offline session against a busy document can cost a second of server CPU; cap the queue by compacting adjacent inserts into one operation before sending. Where two offline users deleted overlapping ranges, OT keeps the document consistent but the result may not be what either meant; the product shows the history so a person can fix it. That honesty matters more to interviewers than claiming perfect merges (sync and conflicts).

How is history stored and restored without replaying a million operations?

The log is append-only and immutable, which makes it cheap to replicate and to compress. Snapshots every 500 operations bound the replay for any revision to 500 transforms. Named versions are just pointers to revisions. Restore is not a rewind: it appends a new operation that replaces the content with the old snapshot, so history stays linear and collaborators mid-edit see the restore as one more change. Old logs move to cold object storage after 30 days, keyed by doc id and revision range, and are fetched lazily when someone scrolls far back in history.

6. What a strong answer sounds like

• Say early that the core problem is ordering concurrent edits per document, and that a single owner node per document is the simplest correct way to get it.
• Explain OT with a two-insert example and state the convergence invariant; mention CRDTs and when they are the better choice.
• Quote the budget: 150 ops a second on a 500-person document is not a scale problem, fan-out is, and it lives in the gateway tier.
• Walk through owner-node failure: snapshot plus log rebuild, client resend with sequence numbers, no lost edits.
• Follow-ups to expect: cursors and presence (broadcast on a separate low-priority channel), permissions revoked mid-session (the router rechecks the ACL every minute and closes the socket), and very large documents (chunk the document and give each chunk its own log).
• A common mistake is to put every keystroke through a database transaction; the database is the log, and the owner node is where ordering happens.

02Where this question was reported

• IGotAnOffer · 'How would you design Google Docs?' (Glassdoor-reported)
• IGotAnOffer · 'How would you design X Google product? (e.g. Google Docs, Google Search, Google Home)'
• IGotAnOffer · Senior/staff: 'collaborative document editing' named as a typical complex-system prompt
• DesignGurus · Listed with step structure
• DesignGurus · 'a flagship Google question', 'one of the hardest', highly valued at senior levels
• Educative · Listed
• System Design Handbook · TPM: 'real-time collaboration across Google Docs'
• Hello Interview · Google Docs breakdown (Hard), tagged Google Drive
• PracHub · 'Collaborative Notes Service', Hard, Apr 2025
• LeetCode Discuss · Started with requirements, use cases, customers; candidate self-scored 3/5 (search snippet)
• Educative · Listed in Google top-10.
• devshreebharatia.substack.com · L5-L6+ list.