Design Google Docs (Collaborative Editing)

In Google Docs, several people can type into the same document at once, see each other's cursors, and always end up with the same text. The core challenge is concurrency: two people editing the same spot at the same moment must converge to one result without anyone's work disappearing.

Requirements#

• Multiple users edit one document in real time; edits appear for others within a few hundred milliseconds.
• Every collaborator eventually sees the same document.
• Show presence: who is viewing, and where their cursors are.
• Offline edits sync when the user reconnects.
• Version history.

Why naive approaches fail#

Suppose the document is abc. Alice inserts X at position 1 while Bob deletes the character at position 2. If each user applies the other's operation as-is, they end up with different documents, because the positions shifted underneath them. We need a way to adjust concurrent operations.

Operational Transformation (OT)#

OT keeps a central server that orders all operations. When an operation arrives that was made against an older version, the server transforms it against the operations that happened since:

// Alice's insert happened before Bob's delete position, so Bob's delete shifts right by one
transform(
  { type: 'delete', pos: 2 },
  { type: 'insert', pos: 1, text: 'X' }
); // → { type: 'delete', pos: 3 }

Google Docs uses OT. It needs a central authority to put operations in order, which suits a server-based product.

CRDTs#

Conflict-free Replicated Data Types give every character a unique, ordered ID (for example a position between its neighbours plus a site ID). Inserts and deletes refer to IDs, not positions, so they can be applied in any order and still converge. CRDTs need no central server, which makes offline and peer-to-peer editing easier. Libraries like Yjs and Automerge use them.

Architecture#

• Each document is owned by one collaboration server at a time (route by document ID with consistent hashing). That server orders operations, so OT stays simple.
• Clients send operations over a WebSocket with the version they were based on, and apply their own edits optimistically.
• The server appends each operation to a log, broadcasts it, and acknowledges the sender.

Storage and history#

• The operation log is the source of truth and gives version history for free.
• Snapshots every few hundred operations mean opening a document doesn't replay its whole history.
• "Named versions" are just bookmarks into the log.

Presence and cursors#

Cursor positions change constantly and don't need durability. Send them over the same socket, throttle to about 10 updates per second, and keep them only in memory.

Offline and reconnects#

A client that was offline buffers its operations. On reconnect it sends them with its last known version; the server transforms them against everything that happened meanwhile. With CRDTs, the client simply merges states.