05. Design a Collaborative Editor

Difficulty: Hard
Interview Focus: CRDT / OT · Real-time Sync · Presence · Conflict Resolution

Interview Question

Design a collaborative rich-text editor where multiple users edit the same document in real time without conflicting overwrites.

Requirements

Functional

Concurrent text editing by multiple users
Cursor / selection presence
Undo / redo that plays well with remote edits
Offline edit then sync
Document load + incremental updates
Basic formatting (bold / lists) if time allows

Non-Functional

Low-latency sync
Convergence (everyone ends in the same state)
Resilient to reconnect / reordering
Accessible editing surface
Scalable to many concurrent editors

Solution

1. High-Level Architecture


Editor UI
    ↓
Local Document Model
    ↓
Sync Engine (OT or CRDT)
    ↓
Realtime Channel
    ↓
Doc Service + Persistence

2. Component Design


CollabEditor
├── Toolbar
├── EditableSurface
├── RemoteCursors
├── PresenceAvatars
└── ConnectionStatus

Keep rendering separate from the sync engine.

3. Sync Flow


Local keystroke
    ↓
Apply locally (instant)
    ↓
Encode op / CRDT update
    ↓
Send to peers / server
    ↓
Apply remote updates
    ↓
Converge document state

4. OT vs CRDT

	OT	CRDT
Model	Transform ops against concurrent ops	Commutative data types
Server role	Often central transformer	Can be peer-friendly
Complexity	Transform edge cases	Metadata / tombstones
Typical use	Google Docs–style	Many modern collab apps

In interviews: pick one, explain trade-offs, don’t claim both casually.

5. Presence


Remote user
    ↓
Cursor position (index / path)
    ↓
Render caret + label
    ↓
Throttle presence updates

Presence is ephemeral — not part of durable document history.

6. Offline & Reconnect

Buffer local updates while offline
On reconnect: exchange missing updates / state vector
Resolve with OT transform or CRDT merge — not last-write-wins on the whole doc

7. Undo / Redo

Local undo stack must invert local operations without wiping remote edits. Prefer stack of invertible ops tied to the sync engine.

8. Performance & Scale

Client: batch keystrokes · throttle presence · avoid full reparse per char · virtualize long docs if needed.

Backend path:


Clients
   ↓
Realtime Gateway
   ↓
Doc Sync Service
   ↓
Blob / op log persistence

Key Decisions

Problem	Solution
Concurrent edits	OT or CRDT (not LWW text)
Same final state	Convergence guarantees
Late packets	Transform / merge by design
Cursor spam	Throttle presence
Offline edits	Buffer + sync on reconnect
Undo vs remote	Invertible local op stack
Large docs	Snapshot + incremental updates

Interview Q&A

Q1. Why not last-write-wins?
LWW drops concurrent character-level intent. Collaborative text needs merge semantics (OT/CRDT).

Q2. OT vs CRDT — which do you pick?
OT if you want a central server model you know well; CRDT if you want simpler peer merge and offline-first. State the trade-off.

Q3. How do cursors stay correct?
Map remote positions through transforms / CRDT positions as the doc changes; throttle updates.

Q4. What do you persist?
Snapshots + op / update log for replay and catch-up; not only the latest blob.

Q5. How do you handle undo?
Undo local ops via the sync engine so remote edits aren’t erased incorrectly.

Q6. How would you scale?
Shard by document, fan-out via pub/sub, compact history with snapshots, limit presence fan-out.

Interviewer Checklist

OT vs CRDT · Convergence · Presence · Offline sync · Undo semantics · Performance · Scalability · Trade-offs

← Real-time Chat · Frontend System Design Index