Design a Real-Time Collaboration Doc (Google Docs)

Problem statement

Design a web-based document editor where multiple users type simultaneously and see each other's changes within about 100 milliseconds. The system must merge concurrent edits without losing a single character, track every cursor and selection, keep a navigable revision history, and tolerate users going offline and returning with queued changes.

The trap in this question is treating it as a rich-text CRUD app with WebSockets bolted on. The real problem is a distributed consistency problem: two clients apply edits to the same document at the same time, over unreliable networks, with no shared clock, and every replica must converge to byte-identical content while every user believes the editor responded instantly. If user A inserts "X" at position 5 while user B deletes position 5, and both edits cross in flight, the system must produce one deterministic result on every screen. That requirement eliminates naive last-write-wins and forces a real concurrency-control algorithm: Operational Transformation (OT), a CRDT, or a central sequencer that imposes total order.

Why this is distinctive

A messaging system delivers immutable events; ordering is per-conversation and messages are never rewritten. A collaborative doc mutates the same shared state from many sites at once, and positions shift under concurrent edits, so every identifier and every cursor is a moving target. Comments anchored to "paragraph three" must survive a thousand edits above them. Revision history must be reconstructable years later. Presence must feel live without polluting the durable state. Each of these is a separate subsystem with a different consistency model, and a strong answer separates them explicitly.

The four planes

Editing plane (client): local optimistic apply, undo/redo, position encoding, buffering and coalescing of keystrokes into operations.
Sequencing plane (server): a per-document total-order authority that assigns revision numbers, transforms concurrent operations, and broadcasts results.
Persistence plane: operation log, periodic snapshots, revision history, comments and metadata, each with its own retention and consistency rules.
Awareness plane: ephemeral presence, cursors, selections, typing indicators. Never persisted, always eventually consistent, always disposable.

The architectural thesis of this answer: the sequencing plane is the only component allowed to decide document order; the editing plane must never block on it; the awareness plane must never touch it.

Public operating baseline

Google reported Google Workspace passing 3 billion monthly active users in 2023, and Docs real-time collaboration traces back through Google Wave's 2010 operational transformation work. Figma publicly described its CRDT-based multiplayer technology in a 2019 engineering post, and Microsoft ships the Fluid Framework with a sequencer-based delta model inside Office and Loop. These establish that the category is solved at planetary scale with two competing algorithmic families. All capacity numbers in this answer that are not attributed are explicit design assumptions, labeled as such.

Key Highlights

•The core problem is deterministic convergence of concurrent mutations, not rich-text rendering.
•Four planes: client editing, server sequencing, durable persistence, ephemeral awareness.
•Only the sequencer decides document order; the editor never blocks on it; presence never touches it.
•Google Workspace reported 3 billion monthly active users in 2023; Docs concurrency descends from Google Wave's OT work.
•Two viable algorithmic families: Operational Transformation and CRDTs; both are production-proven.