Design Google Docs

Each phase is what the interviewer expects you to do and say. Concrete steps, not topic hints. The diagrams are what you sketch on the board.

1. 1

   Clarify Requirements and Scale

   5 min

   GoalPin down the editor paradigm and the concurrency model before drawing anything. Most candidates skip this and end up redesigning halfway through.

   Do & Say

   1. ASK·1ASK: “Rich text like Google Docs, or block-based like Notion, or canvas like Figma? They need different CRDT data models.” Park canvas/block, lock rich text. Write “rich text, ProseMirror tree” on the board.
   2. SAY·2Pin the scale: “10M documents open simultaneously”, “3 concurrent editors average”, “100 peak per document”, “1B total docs”. “That's 30M live WebSockets.” Write “WS=30M, peak 100/doc” top-left.
   3. SAY·3Pin the latency budget out loud: “Local keystroke under 16ms (one 60fps frame)”, “same-region sync under 100ms”, “cross-region under 300ms”. Wait for the nod, write it down.
   4. SAY·4State scope explicitly. In scope: “real-time sync”, “presence/cursors”, “offline editing”, “version history”, “rich text formatting”. Out of scope: “comments threading”, “suggestions mode”, “export to PDF”, “AI assist”. “Pull any back if you want.”
   5. SAY·5Force the offline-editing question now: “Should I design for users editing offline for hours on a plane and merging on reconnect?” “That decision drives OT vs CRDT.” Get a yes, lock it in.

   Interviewer is grading: Picks the rich-text paradigm deliberately, names the 16ms keystroke target unprompted, and forces the offline-editing requirement before any algorithm choice.

2. 2

   Pick the Merge Algorithm (OT vs CRDT)

   8 min

   GoalTwo algorithms on the board. Walk through a concurrent edit with each. End with a defensible choice and a one-line reason.

   Do & Say

   1. SAY·1Write both names: “Operational Transformation (OT)” and “CRDT (Yjs/YATA)”. Say: “Google Docs uses OT, Figma and Notion use CRDTs. Both work. The choice is driven by offline behavior.”
   2. SAY·2Run the canonical example: doc is “HELLO”. “Alice inserts X at pos 1”, “Bob deletes pos 3, concurrently”. “With OT, server transforms ops: Alice's insert stays at 1, Bob's delete shifts from 3 to 4”. “Server is the ordering authority.”
   3. SAY·3Same example with CRDT: “every character has a stable ID like (clock, client)”. “Alice's insert references originLeft=H_id, originRight=E_id”. “Bob's delete tombstones the L item but keeps its ID”. “Merge is order-independent because operations reference IDs, not integer positions.”
   4. SAY·4Say: “Pick CRDT (Yjs) because offline sync is first-class.” “OT forces O(local × missed) transformation on reconnect for a 500-op buffer, and three-user transform-correctness bugs are notorious.” “CRDT gives mathematical convergence and O(m log n) state vector diff.”
   5. WATCH·5Get ahead of the metadata pushback: “Yes, CRDTs carry per-character metadata, originLeft and originRight pointers”. “Naive CRDTs blow up to 16x plain text size”. “Yjs's optimized binary encoding with run-length encoding for consecutive edits brings it down to 1.5 to 3x”. “That's the trade-off I'm taking.”
   6. SAY·6Name the server's role explicitly: “The server is a relay, not a merge authority.” “Hocuspocus persists ops and broadcasts them.” “The merge intelligence is on the client.” This is the load-bearing sentence.

   Interviewer is grading: You name OT and CRDT, you can walk the HELLO example through both, and the choice is justified by offline behavior, not vibes. You volunteer the metadata-overhead trade-off before being asked.

3. 3

   High-Level Design

   10 min

   GoalOne diagram. Client holds the full Yjs document, server is a relay, persistence is operation log plus periodic snapshots. Label the WebSocket and the Redis Pub/Sub hop.

   Draw on the board
   Do & Say

   1. DRAW·1Draw the client first and label it heavy. “The client holds the full Yjs document in memory, persists to IndexedDB, and renders through TipTap on top of ProseMirror.” “Local edits commit instantly to IndexedDB.” “No server round-trip on the keystroke path.”
   2. DRAW·2Draw the WebSocket and label it “binary Yjs update, ~30 bytes per character insert”. Say: “Custom binary protocol on WebSocket, not JSON.” “A run of 100 same-user characters encodes as one item, ~120 bytes, because of run-length encoding.”
   3. DRAW·3Draw the Hocuspocus tier and call out: “Consistent hashing on document_id routes every editor of one doc to the same Hocuspocus instance.” “That's the primary defense against split-brain.” “The Yjs document lives in that instance's memory.”
   4. DRAW·4Draw the Redis Pub/Sub box and label the channel “hocuspocus:document_id”. Say: “During failovers, scaling events, or rolling deploys, two editors can land on different instances.” “@hocuspocus/extension-redis relays updates between them through Pub/Sub.” “CRDT commutativity means out-of-order or duplicate delivery is harmless, so the relay doesn't need to be ordering-correct.”
   5. DRAW·5Draw persistence: “Postgres holds op log and snapshots every 500 ops or 5 min, whichever first”. “S3 is cold storage”. “Redis caches hot doc state for sub-ms access”. “Cold load from Postgres snapshot plus replay takes 500ms-1s for large docs”. “The under-100ms target applies to steady-state, not cold opens.”
   6. SAY·6Storage math: “1B docs at 10KB avg is 10TB content”, “100TB compacted op logs”, “50TB snapshots”, “300TB media”. “~460TB total.” “WebSocket fleet is 30M connections at 50K per box, so ~600 gateway boxes.” “Sync tier 1,000 Hocuspocus instances at 10K active docs each.”

   Interviewer is grading: Client is drawn as heavy and authoritative. Server is drawn as a relay. The Redis Pub/Sub channel is named and its role is justified by failover, not steady state. You volunteer the cold-load latency carve-out.

4. 4

   Deep Dive: Presence, Offline, and Split-Brain

   12 min

   GoalThree sub-dives that every interviewer asks about. Have a one-paragraph answer for each, with a concrete data structure.

   Draw on the board
   Do & Say

   1. SAY·1Presence sub-dive: “Cursors use Yjs relative positions, not integer offsets.” “A relative position anchors to a CRDT item ID.” “When Bob inserts before Alice's cursor, Alice's cursor stays correct because it references item (155, alice), not position 5.” Draw awareness payload with “anchor”, “head”, “user color”, “status”.
   2. SAY·2Mention the throttle number: “Awareness updates are debounced at 50ms, so up to 20 per second per user.” “At 100 editors on a hot doc, that's about 2,000 presence messages per second, around 400KB/s.” “Presence is actually heavier than edits in a busy room.”
   3. SAY·3Presence persistence: “Never persisted.” “Not to Postgres, not to disk Redis, only through ephemeral Pub/Sub.” “Disconnected clients drop off after 90s heartbeat.” “If you want last-seen, that's a separate REST audit log, not the awareness protocol.”
   4. SAY·4Offline sub-dive: “User offline on a plane, 500 ops over four hours, reconnects.” “With OT this is a brutal O(500 × concurrent) transform matrix.” “With Yjs the client sends its state vector, server diffs and ships only missing ops.” “Convergence is mathematical.” Draw the state vector exchange.
   5. SAY·5Split-brain sub-dive: “Two Hocuspocus instances briefly hold the same doc during failover, each broadcasts to its clients, edits diverge for seconds.” Three defenses: “Consistent hashing prevents most cases”, “extension-redis catches scaling and failover gaps”, “CRDT convergence plus persist-layer merge guarantees eventual correctness”.
   6. SAY·6Doc-too-large pushback: “A 1.5M-char doc with 100 editors hits ~50MB of Yjs state on the sync server.” “We cap docs at 1.5M chars (~500 pages) and GC tombstones during snapshot creation, but only when every connected client has integrated the deletion.”
   7. WATCH·7Be ready for the hot-document question: “A 100-editor document is the hard limit.” “Beyond that, the broadcast amplification becomes the bottleneck, not Yjs merging.” “We'd need to shard the document into sub-documents, which is the block-based architecture, not what this design supports.”

   Interviewer is grading: You name relative positions for cursors and explain why integer offsets break. You volunteer the three-layer split-brain defense without prompting. You give concrete numbers for awareness throttling and document size limits.

5. 5

   Trade-offs and Wrap-up

   5 min

   GoalTwo deliberate trade-offs, one operational tail risk, one-sentence summary.

   Do & Say

   1. SAY·1Metadata trade-off: “I'm taking 1.5 to 3x plain-text storage overhead for tombstones and origin pointers.” “The win is offline-first correctness.” “Periodic snapshot GC keeps tombstones from growing forever, but only when every connected client has seen the deletion.”
   2. SAY·2WebSocket trade-off: “WebSocket through corporate proxies is blocked ~1-3% of the time in 2026.” “Ship a long-polling fallback for those users with 300-500ms sync and a compatibility-mode banner.” “Google Docs and Notion accept this rather than building a fully separate transport.”
   3. SAY·3Operational risk: “The biggest tail risk is a Postgres write-amplification storm if the op log isn't batch-flushed.” “At 60M ops/sec steady state, single-row inserts would crater the primary.” “We batch inserts in 100ms windows and shard the op log across 100+ Citus nodes keyed by document_id.”
   4. SAY·4Close: “Relay-server architecture.” “Client owns the merge via Yjs CRDT, server only persists and broadcasts, presence rides the same WebSocket.” “Consistent hashing plus Redis Pub/Sub plus persist-layer merge is the three-layer split-brain defense.” “Load-bearing decision is CRDT over OT, justified by offline-first.”
   5. SAY·5Offer deeper dives if there's time: “Peritext for rich-text marks”, “the Hocuspocus persistence hooks”, or “how block-based editors like Notion differ from this single-document model”.

   Interviewer is grading: Trade-offs are named with a number attached ('1.5-3x overhead', '1-3% proxy block rate'). Closing summary names the load-bearing decision. Offers specific deeper-dive options, not generic 'we can talk about anything'.

Questions an interviewer is likely to ask after your walkthrough. Rehearse the short answer.

1. Why CRDT and not OT, since Google Docs uses OT?
2. How do you prevent split-brain when a Hocuspocus instance fails over?
3. What happens when a document has 100 concurrent editors?
4. Why are presence updates never persisted?
5. Walk me through a cold document load.
6. How does the Yjs binary protocol compare to JSON?
7. What's the failure mode for WebSocket through corporate proxies?
8. Why Postgres and not a NoSQL store for the op log?