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.
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
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?
Local-first application makes the UI feel instant while the operation syncs with the server and other clients in the background.
2. What problem do Operational Transformation and CRDTs both solve?
Both are concurrency-resolution strategies that let multiple simultaneous editors converge deterministically without losing edits.
3. How does a new client typically reconstruct document state when joining a long collaborative session?
Snapshot plus recent operation replay avoids replaying an entire session history for every new joiner.
Flash Cards
Two main concurrency-resolution strategies? — Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs).
Why apply edits locally first? — To keep typing latency near zero before server/network round-trip confirms the change.
How do new clients join mid-session? — By loading a periodic snapshot plus operations since that snapshot.
Where does presence/cursor data live? — As ephemeral, non-authoritative metadata separate from the durable operation log.