How to Design a Collaborative Document Editor

Design a Google Docs-style editor: local-first edits, OT vs CRDT merging, snapshots, and presence for real-time collaboration.

hardQ94 of 224 in System Design Est. time: 6 minsLast updated: July 2026

Open Code Lab

Expected Interview Answer

A collaborative document editor (like Google Docs) lets multiple users edit the same document simultaneously by converting each keystroke into an operation, broadcasting operations to all connected clients, and using either Operational Transformation (OT) or Conflict-free Replicated Data Types (CRDTs) to merge concurrent edits deterministically so every client converges to the same final document state.

Each client applies edits locally immediately for responsiveness, then sends the operation (insert/delete at a position) to a central server, which broadcasts it to other connected clients over a WebSocket. Because two users can edit concurrently before either sees the other's change, the server (in OT) transforms incoming operations against any operations that happened concurrently so they apply correctly regardless of arrival order, or (in CRDTs) each character/element carries a unique, comparable identifier so operations can be merged commutatively without a central transform step. The document's canonical state is periodically persisted, and new clients joining mid-session first fetch a snapshot plus any operations since that snapshot to reconstruct current state. Presence cursors, comments, and selection highlighting are layered on top as ephemeral, non-authoritative metadata broadcast alongside the operation stream.

Local-first application of edits keeps typing latency near zero for the editing user
OT/CRDT merge logic guarantees all clients converge to the same document despite concurrent edits
Snapshot plus operation log lets new clients join mid-session without replaying full history
Separating ephemeral presence data from the operation log keeps the durable log lean

AI Mentor Explanation

A collaborative document editor is like two scorers updating the same match ledger simultaneously from different ends of the ground. Each scorer records what they see immediately in their own notebook (local-first apply), then radios their entry to a central desk which reconciles both notebooks so a run recorded from one end and a wicket from the other end merge into one consistent official ledger regardless of which radio call arrived first (operational transform). A third scorer joining mid-match just grabs the current ledger snapshot plus recent radio calls instead of replaying the entire match. That local-apply-then-reconcile design is exactly how a collaborative document editor merges simultaneous edits.

Step-by-Step Explanation

Step 1
Apply edits locally first
The editing client applies keystrokes to its own document copy immediately for zero-latency feel.
Step 2
Send the operation to the server
The client sends a structured insert/delete operation with its position to a central sync server.
Step 3
Transform or merge concurrent operations
The server (OT) transforms operations against concurrent ones, or (CRDT) merges via unique element identifiers.
Step 4
Broadcast and converge
The resolved operation is broadcast to all other clients, which apply it so every client converges to the same document state.

What Interviewer Expects

Names Operational Transformation and/or CRDTs as the concurrency resolution mechanism
Explains local-first application for responsiveness before server confirmation
Describes how new clients join mid-session via snapshot plus operation replay
Distinguishes ephemeral presence/cursor data from the durable operation log

Common Mistakes

Proposing last-write-wins for concurrent character edits, which loses data
Not explaining how concurrent operations are transformed or merged deterministically
Forgetting how a document is reconstructed for a client joining mid-session
Conflating cursor/presence broadcasting with the durable edit history

Best Answer (HR Friendly)

“A collaborative document editor lets your typing show up instantly on your own screen, then sends that change to a server which figures out how to combine it with everyone else's changes so everyone ends up seeing the exact same document. It uses techniques like operational transformation or CRDTs to make sure edits made at the same time by different people merge cleanly instead of overwriting each other.”

Code Example

Simplified operational transform (pseudo-code)

function transform(opA, opB) {
  // both are insert operations; adjust position if opB happened
  // at or before opA's original position
  if (opB.type === "insert" && opB.position <= opA.position) {
    return { ...opA, position: opA.position + opB.text.length }
  }
  if (opB.type === "delete" && opB.position < opA.position) {
    return { ...opA, position: opA.position - opB.length }
  }
  return opA
}

function applyIncomingOperation(localDoc, incomingOp, pendingLocalOps) {
  let transformed = incomingOp
  for (const localOp of pendingLocalOps) {
    transformed = transform(transformed, localOp)
  }
  return applyOperation(localDoc, transformed)
}

Follow-up Questions

How do CRDTs differ from Operational Transformation for resolving concurrent edits?
How would you design cursor and selection presence without bloating the operation log?
How do you reconstruct document state efficiently for a client joining an hour-long session?
How would you handle rich formatting (bold, tables) instead of just plain text insert/delete?

MCQ Practice

1. Why do collaborative editors apply edits locally before the server confirms them?

2. What problem do Operational Transformation and CRDTs both solve?

3. How does a new client typically reconstruct document state when joining a long collaborative session?

Flash Cards

1 / 4

How to Design a Collaborative Document Editor

Expected Interview Answer

AI Mentor Explanation

Step-by-Step Explanation

Apply edits locally first

Send the operation to the server

Transform or merge concurrent operations

Broadcast and converge