Picture two colleagues writing on the same physical whiteboard from opposite ends of the room. They can both write simultaneously without bumping into each other, as long as they stay in separate areas. But the moment they both try to edit the same sentence - one crossing out a word while the other rewrites it - you need a referee, a way to reconcile two independent histories into one coherent result. Google Docs does this for millions of simultaneous writers across the internet, with a 90ms round-trip constraint and no referee standing by to adjudicate disputes.

The scale makes the challenge concrete: at peak, Google Docs serves tens of millions of concurrent document sessions. A popular shared document might have dozens of people editing simultaneously, each on different network connections with different latencies. Every keystroke a user types must feel instant on their own screen - that means applying it locally without waiting for server acknowledgment. Yet that same keystroke must somehow be reconciled with edits from every other user and result in a document that looks identical on all screens within a few hundred milliseconds.

Naive approaches collapse immediately under this constraint. Last-write-wins destroys work: if Alice types “Hello” and Bob simultaneously types “World” in the same position, one of them loses their edit entirely. Pessimistic locking prevents the problem but also prevents concurrency - only one user can type at a time, which is useless for a real-time collaboration tool. Simple merging strategies like operational queuing break when network partitions occur or when a user goes offline and makes edits that need to be reconciled later.

The forces in tension are: latency vs consistency (applying locally is fast but potentially wrong), offline support vs convergence (users need to edit without connectivity, but their changes must merge correctly later), and simplicity vs correctness (simpler algorithms break on edge cases that real users hit constantly). We need to solve three core problems: conflict-free concurrent editing (two edits to the same location must both survive and be applied in a way that preserves both users’ intent), cursor position stability (when Alice inserts text before Bob’s cursor, Bob’s cursor must jump forward automatically), and offline convergence (edits made without network access must reconcile correctly when connectivity returns).

Requirements and Constraints

Functional Requirements

• Multiple users can edit the same document simultaneously with their changes visible to all others in real time
• Each user’s cursor position and selection range is broadcast to all other active collaborators
• Users can edit offline and have their changes merged automatically when they reconnect
• Full document version history with per-operation attribution and the ability to restore any prior state
• Presence indicators showing which users are currently active in the document and their cursor positions
• Document is always in a readable, consistent state - no partial operations or half-applied edits visible to any user

Non-Functional Requirements

• Operation propagation latency under 100ms for 99th percentile from client submission to all connected peers seeing it
• 99.99% availability - editing must degrade gracefully, never block on a single server failure
• Support for millions of concurrently active documents, each potentially with dozens of simultaneous editors
• Strong eventual consistency - all clients that receive the same set of operations must converge to identical document state, regardless of operation arrival order
• Cursor updates propagated within 50ms to minimize cursor teleportation on peers’ screens

Constraints

• No pessimistic locking - users must never be blocked from typing by another user’s activity
• Operations must commute - applying operation A then B must yield the same result as B then A after transformation
• The convergence guarantee is the hard invariant - the system may sacrifice ordering guarantees but never convergence

High-Level Architecture

The system is composed of seven major components. The Client SDK runs in the browser, applying operations optimistically to the local document state and queuing them for transmission. The WebSocket Gateway manages persistent connections and routes messages to the correct document session. The Operation Service sequences incoming operations and applies the OT or CRDT transformation logic. The OT/CRDT Engine is the mathematical core that transforms concurrent operations so they can be safely applied. The Document Store persists the canonical document state, operation log, and version snapshots. The Presence Service tracks which users are active and their cursor positions. The Cursor Broadcast Service fans out cursor updates to all peers with minimal latency.

When a user types a character, the Client SDK immediately applies it to the local document (optimistic application) and emits an operation to the WebSocket Gateway over the persistent connection. The gateway routes the operation to the Operation Service responsible for that document’s session. The Operation Service assigns a sequence number, transforms the operation against any concurrent operations that arrived first, and persists it to the Document Store. The transformed operation is then broadcast to all other connected clients via the WebSocket Gateway. Each receiving client applies the operation to their own document state, using the same transformation logic to ensure convergence.

Component Deep Dives

The Operation Engine

The Operation Engine is the heart of the system - the component that makes concurrent edits safe. Think of it like a court reporter at a deposition where multiple witnesses are speaking at once: the reporter must transcribe every word accurately, even when two people speak simultaneously, and produce a single coherent transcript that faithfully represents what everyone said.