Design a Collaborative text editor

01Concrete scale assumptions

02Architecture decisions and rationale

03Client contracts and data boundaries

1type OpEnvelope = { documentId: string; actorId: string; seq: number;2  deps: Record<string, number>; payload: Uint8Array; };3type SyncMessage =4  | { type: 'ops'; ops: OpEnvelope[] }5  | { type: 'ack'; actorId: string; throughSeq: number }6  | { type: 'snapshot'; version: string; bytes: Uint8Array };

04Failure-mode analysis

05Observability and operations

• Measure local apply latency, remote propagation, reconnect duration, pending-op depth, merge failures, and snapshot load time.
• Trace document session and actor ids while avoiding document content in logs.
• Alert on causal gaps, repeated reconnect loops, and operation rejection rates.
• Run deterministic convergence simulations with reordered, duplicated, delayed, and offline operation sequences.

06Security and accessibility boundaries

• Authorize document membership on connection and every mutation; an opaque document id is not permission.
• Encrypt transport, constrain pasted rich content, and sanitize exports and embeds.
• Expose semantic document structure, keyboard editing, collaborator names, and non-color cursor distinctions.
• Announce collaborator joins and edits sparingly so live updates do not overwhelm screen-reader users.

ANSOne full answer, start to finish

Drive the discussion yourself first. This is one strong answer delivered the way you would say it in the room — a model, not the only correct design.

The trap here is trying to invent your own text-merging on the spot. Do not. Name a proven family of algorithm, explain the local-first idea, and spend your time on the two things that actually matter: how edits merge without a lock, and why cursor positions travel on a completely separate channel from the text itself.

1. Step 1 · Clarify the scope

   Ask: 'How many people edit one document at once — a handful, or hundreds? Plain text or rich text with formatting? Does it need to work offline and sync later? And do we need per-user undo?' State assumptions: 'I will assume up to about 20 active editors per document, rich text, offline support needed, and undo that only undoes my own changes.' The offline and undo answers change the algorithm choice, so it is worth asking.

2. Step 2 · Requirements, user-facing and hidden

   User-facing: type and see it instantly, see other people's cursors and selections, and never lose an edit to a conflict. Hidden: edits from different people must combine to the same final document on every screen without anyone taking a turn, the server must be the durable record, and presence (cursors) can be lossy but the document cannot.

3. Step 3 · Name the merge approach

   'I would use a conflict-free replicated data type, a CRDT, or operational transformation — both are well-studied ways to turn each person's edit into an operation that combines correctly with other people's concurrent operations. I would not hand-roll text diffing; that is where these systems break. CRDTs tend to suit offline-first; OT needs a central server but carries less metadata. Given the offline requirement I lean CRDT.'

4. Step 4 · Local-first, then draw the boxes

   'Every keystroke is applied to the local copy immediately — that is what makes typing feel instant even on a slow connection — and also turned into an operation sent to the server. The server puts operations into a consistent order (or transforms them) and broadcasts them to everyone else, and also stores the authoritative document. Each client applies incoming operations through the same merge logic and converges. So: a thin editor UI, a merge engine, a WebSocket transport, a server that orders and persists.'

5. Step 5 · Presence is a separate channel

   'Cursor and selection updates go on a different channel from document operations. They can be sent more often, they can be dropped, and they expire on their own — if a cursor update is lost, nothing breaks. Document operations are the opposite: they need ordering, deduplication, persistence, and guaranteed eventual delivery. Mixing them means either the cursors are too heavy or the edits are too fragile.'

6. Step 6 · Reconnect and undo

   'On reconnect, the client and server compare what versions each has seen, the client pulls the operations it missed, replays any local operations it made offline (idempotently, so replaying twice is safe), and the merge engine settles. Undo is defined as creating the inverse of my own last intention in the current merged state — not restoring an old snapshot of the whole document, which would wipe out other people's work.'

7. Step 7 · The frontend bottleneck

   'The performance risk is not the merging, it is rendering a large document and re-mapping every cursor and selection on each change. I would render only the nodes an operation actually touched and keep the merge work off the expensive layout path.'

QAInterview questions and model answers