FSD Frontend System Design

Part VI — The Blueprint · Lesson 11.11

HLD – Google Docs

In one lineTwo people typing in the same paragraph is the entire problem — OT or CRDT is the answer.

Where you've seen itTwo colleagues typing into one sentence, and the result reading correctly for both of them.

  • Time21 min
  • DiagramConcurrent edit conflict + OT vs CRDT resolution
  • Chapter11 · High Level Design

Diagram

diagram
1–2 · SCOPE AND SCALE

  in scope   rich text editing · multi-user cursors · comments ·
             offline editing · version history
  out        export pipeline · sharing permissions UI · print
  scale      docs up to ~100k words · 2–20 concurrent editors
             sub-100ms local echo is non-negotiable
diagram
3 · THE CORE PROBLEM — naive sync loses data

  both start with:  "Hello"

  Alice inserts "!" at 5        Bob inserts " world" at 5
       "Hello!"                      "Hello world"
           │                              │
           └──────────► server ◄──────────┘
                          │
              last-write-wins ⇒ ONE EDIT IS LOST ✗

  Text needs index transformation. This is why 11.9's
  last-write-wins was fine for shapes and is fatal here.
diagram
6a · DEEP DIVE — OT vs CRDT

  OPERATIONAL TRANSFORM (OT)
    ops carry positions; the server transforms each incoming op
    against ops it has already applied

    Bob's insert@5  ──transform against Alice's insert@5──► insert@6
    result: "Hello! world"   both edits survive

    ✓ compact ops · ✗ needs a central server · ✗ hard to prove correct

  CRDT (Yjs, Automerge)
    every character gets a unique, ordered id; merges are
    commutative — order of arrival doesn't matter

    ✓ works peer-to-peer and offline · ✓ provably convergent
    ✗ metadata overhead per character · ✗ heavier payloads

  Choose OT if you already have an authoritative server.
  Choose CRDT if offline and P2P matter. Say WHY, either way.
diagram
6b · DEEP DIVE — LATENCY AND PRESENCE

  local echo    apply the keystroke to the local model IMMEDIATELY
                (never wait for the server — typing must feel free)
                     │
                     ├─► render
                     └─► queue op → server → broadcast → peers

  presence      cursors + selections, ~20Hz, throttled,
                sent on a SEPARATE ephemeral channel — never
                persisted, never part of the document history

How it works

  1. The document is a data model, not the DOM — a tree of blocks with marks. Rendering derives from it.
  2. Local echo first: apply, render, then send. Any perceptible delay makes typing feel broken.
  3. Sync via OT or CRDT over WebSocket (2.4), with an explicit reconnect-and-catch-up path.
  4. Presence is ephemeral and travels separately from document operations.
  5. Offline buffers ops locally (9.1) and merges on reconnect — CRDTs make this trivial, OT makes it work with server help.

Trade-offs

ChoiceCost
OTCompact, mature, server-dependent, tricky to implement
CRDTOffline-friendly, convergent, larger payloads
contentEditableNative input/IME; famously inconsistent across browsers
Custom-rendered editorFull control; you rebuild IME, selection, and a11y

Accessibility (8.3): rich-text editors are one of the hardest a11y surfaces — announce collaborator changes politely without spamming, keep keyboard shortcuts discoverable, and never move the user's cursor because of a remote edit.

Interview angle

"Two users type in the same sentence. How does it not break?"

  • Position indices shift under concurrent edits, so raw last-write-wins loses one of them.
  • OT transforms incoming operations against already-applied ones; CRDTs give every character a unique id so merges commute.
  • I'd pick based on constraints — OT with an authoritative server, CRDT if offline or peer-to-peer editing is required — and I'd apply locally first so typing never waits on the network.

Recap

  • Concurrent text editing is the problem; OT and CRDT are the two real answers.
  • Local echo immediately; sync in the background.
  • Presence is ephemeral and separate from document history.