Design Google Docs: Collaborative Editing for Millions

The Impossible-Sounding Problem

Imagine 50 people editing the same Google Doc simultaneously. Each person types at about 200 characters/minute. That is 10,000 character insertions per minute hitting the same document, each at different positions, each arriving over the network with different latency. Yet every person sees the same document, in real time, with no corruption. The algorithm that makes this work - Operational Transform - is one of the most elegant solutions in distributed systems.

Why Naive Concurrent Editing Fails

The Concurrent Edit Problem:

  Document: 'Hello'  (5 characters, positions 0-4)

  User A: Insert 'X' at position 1 -> 'HXello'
  User B: Delete character at position 4 -> 'Hell'

  Both operations sent to server simultaneously.

  If server applies A then B:
  'Hello' -> 'HXello' -> delete pos 4 -> 'HXelo' (wrong!)
  User B wanted to delete 'o', but deleted 'l' instead.

  Why? B's position (4) was calculated on the ORIGINAL
  document, but A's insert shifted everything by 1.

  Operational Transform fixes this:
  Transform B against A:
  'Delete at position 4' + 'Insert at position 1'
  -> 'Delete at position 5' (shifted by 1)

  Server applies A then transformed-B:
  'Hello' -> 'HXello' -> delete pos 5 -> 'HXell' (correct!)

System Architecture

Google Docs Architecture:

  [User A Browser]     [User B Browser]     [User C Browser]
       |                    |                    |
  WebSocket              WebSocket            WebSocket
       |                    |                    |
  [Document Server]  (one per active document)
       |
  Responsibilities:
  1. Assign monotonic revision numbers to operations
  2. Transform concurrent ops against each other
  3. Broadcast confirmed ops to all connected clients
  4. Persist operation log to Bigtable
       |
  [Bigtable / Spanner]
  Stores: full operation history per document
  Enables: undo, version history, time travel
       |
  Operation log (append-only):
  rev 1: insert('H', pos=0, user=A, ts=14:30:01)
  rev 2: insert('e', pos=1, user=A, ts=14:30:02)
  rev 3: insert('!', pos=5, user=B, ts=14:30:02)
  ...

  Document state = replay all operations from rev 0

OT vs CRDTs

Comparing Collaboration Algorithms:

  Feature          OT (Google Docs)      CRDTs (Figma)
  ──────────────   ───────────────────  ─────────────────
  Server needed?   Yes (central OT)      No (peer-to-peer)
  Offline support  Limited               Full
  Complexity       Server-side transform  Client-side merge
  Scaling          1 server per doc       No bottleneck
  Proven at scale  Google, Microsoft      Figma, Apple Notes

  OT: simpler to implement, needs central server
  CRDTs: no server needed, but complex data structures

  Google chose OT because they already have
  the server infrastructure and want centralized control.

Interview Tip

When designing a collaborative editor, explain the concurrent operation problem with a concrete example (two users editing same position). Then explain OT: the server transforms each operation against all concurrent operations before applying it. Cover WebSocket connections per document, monotonic revision numbers for ordering, and operation logs stored for undo/history. Mention CRDTs as an alternative (peer-to-peer, no central server) and explain the trade-off.

<

/blockquote>

Key Takeaway

Google Docs uses Operational Transform over a WebSocket architecture with a central server that serializes and transforms all concurrent operations. The server assigns revision numbers that allow clients to reconcile their local pending operations with received server operations. Real-time cursor sharing is a separate, transient presence system.