Design a Collaborative Document Editor

Prompt

"Design Google Docs: many people edit the same document at once, everyone sees everyone else's changes within a second, and nobody loses work."

Clarifying questions

• What is the document? Rich text: characters with formatting attributes, paragraphs, and simple embedded objects. Spreadsheets and drawings are different problems.
• How many concurrent editors per document? Typically a handful; support up to a few hundred with graceful degradation. Viewers may be thousands.
• Latency? A local edit appears instantly for its author; remote edits should appear within a few hundred milliseconds under normal conditions.
• Offline editing? Yes: a client that loses connectivity keeps editing locally and reconciles on reconnect.
• History? Full revision history with the ability to view and restore any point.
• Presence? Cursors and selections of other editors, plus "who is here".
• Conflict resolution? Automatic. Users should never be asked to merge; concurrent edits converge to the same document for everyone.
• Scale? Hundreds of millions of documents, tens of millions of daily active editors.

Requirements

Functional

• Real-time collaborative editing with automatic convergence.
• Per-document revision history and restore.
• Presence and cursors.
• Offline editing with reconciliation.
• Permissions (view, comment, edit) enforced on every operation.

Non-functional

• Convergence: all clients that have seen the same set of operations show identical documents.
• Intention preservation: a user's edit means the same thing after concurrent edits are merged (inserting "x" after "abc" still lands after "abc").
• Durability: an acknowledged operation is never lost.
• Low latency for the collaboration loop; the server must add only milliseconds.

Back-of-envelope

• Editors: assume 20M daily active editors, each editing for 30 minutes/day at 2 operations/s while typing (each keystroke or small batch is one operation). 20M × 1,800 s × 2 = 72B operations/day ≈ 830,000 operations/s average, 2M/s at peak. This number says the operation path must be cheap and horizontally scaled by document.
• Concurrent documents: if each editor's session touches one document and sessions overlap, roughly 20M × (30 min / 1,440 min) ≈ 400,000 documents open at any moment, most with a single editor. Only a small fraction have concurrent editors, which is where the merge logic matters.
• Operation size: a keystroke op is about 50 B on the wire (position, character, revision number, client id). Peak inbound is 2M × 50 B = 100 MB/s. Broadcasting each op to the other editors of the document multiplies this by the average concurrent editor count minus one; with skew it is a few hundred MB/s outbound. Modest.
• Storage: every operation is appended to the document's log. 72B ops/day × 50 B = 3.6 TB/day of raw log, about 1.3 PB/year before compaction. Snapshots at intervals let old logs be compacted or moved to cold storage; keep the log for history but not in the hot store.
• Connections: 20M editors with, say, 1.5M connected at peak plus viewers; persistent connections spread across a fleet of connection servers at a few hundred thousand per node → a fleet of about a dozen to a few dozen nodes with headroom. The constraint is connection count, not bandwidth.