Design Google Docs (Collaborative Editing)

The Real-Time Concurrency Challenge

In a standard text editor, saving a file overwrites the previous version. If multiple users edit a shared document simultaneously over the web, overriding fails: User A's save will overwrite User B's edits.
Locks also fail: locking a document for editing prevents true real-time collaboration.

To support real-time editing, the system must receive character insertions and deletions from multiple clients and merge them so that **all users eventually see the exact same document sequence** (Convergence).

Two Collaborative Editing Paradigms

Used by Google Docs and Apache Wave.
Operations (Insert/Delete) are represented 
relative to index positions.

A central server sequences all incoming edits, 
re-calculates (transforms) character indexes, 
and broadcasts adjustments to clients.

✓ Low memory footprint.
✗ Hard to implement; requires a single 
  centralized sequencing server.

Used by Figma, Apple Notes, and Yjs.
Characters are treated as distinct mathematical 
objects with globally unique fractional IDs.

Clients apply edits locally and broadcast them. 
Operations merge deterministically in any order, 
without server transformation.

✓ Decoupled: works in peer-to-peer setups.
✗ Higher memory overhead due to metadata.

Operational Transformation Walkthrough

Let's look at a classic OT collision. Document state starts as: "cat".

• Client A inserts 's' at index 0. Document becomes "scat".
• Client B concurrently inserts 's' at index 3 (after 't'). Document becomes "cats".
• If the server processed Client A's edit first, it receives Client B's edit (insert 's' at index 3). However, because Client A inserted a character at index 0, Client B's edit index must be incremented by 1.
• The server transforms Client B's edit to "insert 's' at index 4", broadcasts it, and both clients reach the correct convergent state: "scats".

Real-Time Architecture Components

• WebSocket Servers: Maintain persistent connections to active document editors to relay operations with sub-second latency.
• Operational Sequencer (OT server): A stateful microservice dedicated to ordering edits for a specific document ID. It caches active document states in memory (Redis) and periodically saves snapshots to a database.
• Document Store (NoSQL/Relational): Stores the compressed document text blocks and audit logs of editing operations.
• Presence Service: Tracks cursor positions and user selections, broadcasting coordinates over WebSockets to show where other editors are active.