Design Google Docs (Real-Time Collaborative Editing)

Collaborative editing looks deceptively simple — multiple users type into the same document. The hard part is concurrent edit convergence: two users edit the same paragraph simultaneously, and both edits must be applied to both clients in a consistent order, producing the same final document. The naive solution — last-write-wins or pessimistic locking — either loses edits silently or serializes users to single-writer throughput, defeating the purpose of collaboration. The correct abstraction requires a formalism that guarantees two properties: convergence (all replicas that have seen the same set of operations end up with the same document state) and intention preservation (applying an operation produces the result the user intended, not a corrupted version). Getting both properties simultaneously under concurrent, out-of-order operation delivery is the core research problem. Two families of solutions have emerged over 30 years: Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs). Google Docs uses OT. Notion and many newer systems use Yjs (a CRDT library). The wrong answer in an interview is picking one without explaining why and what the tradeoffs are. At Google Docs scale — over 1 billion documents, millions of simultaneous collaborative sessions, ~30 ops/min per active document — the system processes hundreds of thousands of operations per second globally, with a WebSocket latency target under 100ms from keystroke to peer delivery. Every architectural decision is downstream of concurrent edit correctness, not throughput.