Staff · 45 min

Collaborative Document Editor

Also asked as: Google Docs, Notion, Confluence, Dropbox Paper.

The Prompt

Read it once, then start the timer and work without scrolling.

Design the frontend for a collaborative rich-text editor where multiple people edit the same document at the same time and see each other's cursors.

Everything below is a model answer. You will get far more out of this drill by attempting it cold first — set the timer, talk through it out loud, and only then compare.

Rehearse with Timer

A 45-minute phase plan you can practise against a clock.

Interactive · Drill rehearsal timer

Clarify and scope

6:00

Pin down concurrent editor count and offline expectations first — they drive every later decision
Explicitly descope what you will not design: auth, billing, mobile native, the storage backend
State the one thing you consider the crux: conflict resolution on a shared mutable structure

Requirements

What you should establish before drawing a single box.

Clarifying questions

How many concurrent editors per document — 5, or 500? That decides whether presence can be a simple broadcast or needs fan-out infrastructure.
Is offline editing required, or is a read-only degraded mode acceptable when the socket drops?
Do we need the full formatting surface, or is this plain text with comments? Rich text is what forces CRDT/OT rather than naive last-write-wins.
Is there a hard requirement that no edit is ever lost, or is a conflict banner acceptable in rare cases?
Who owns the merge algorithm — are we adopting Yjs or Automerge, or is the backend team building it?

Functional

Multiple users edit the same document concurrently with sub-second convergence
Live presence: remote cursors, selections, and participant avatars
Formatting (bold, headings, lists) that survives concurrent edits
Comments anchored to text ranges that survive edits to surrounding text
Document history with the ability to restore a prior version

Non-functional

Local keystroke echo under 16ms so typing never feels laggy
Remote edits visible within roughly 200ms on a healthy connection
No lost edits across a reconnect, including a 30-second offline window
Documents up to ~100k words without editor jank
Graceful read-only degradation rather than a blank screen when realtime fails

Model Answer

Architecture, data, interfaces, and optimisations — the RADIO body.

Architecture

Three-layer state model: document (durable, convergent), presence (ephemeral, lossy), local UI (never synced)
A CRDT document store (Yjs) as the single source of truth in the client, with the editor view rendered from it
An editor binding layer (ProseMirror or Lexical) that translates DOM events into CRDT transactions rather than mutating the DOM directly
A WebSocket provider that ships CRDT updates as binary deltas, not full document snapshots
An IndexedDB persistence provider so a reload or a disconnect never loses local work
A separate presence channel with a shorter TTL so a crashed tab's cursor disappears without manual cleanup

Data model

Document is a CRDT tree (Y.XmlFragment) rather than a plain string, so concurrent inserts at the same index both survive
Each edit is a delta keyed by (clientId, clock) — this pair is what makes operations idempotent on replay
Comments store a relative position (CRDT-anchored) rather than an absolute character offset, so they do not drift when text above them changes
Presence records are {clientId, userId, cursorAnchor, selectionHead, color, lastSeenAt} with a TTL of a few seconds
Version history stores periodic snapshots plus the delta log between them, because replaying all deltas from zero gets slow

Interfaces and contracts

WebSocket messages: sync-step-1 / sync-step-2 for initial handshake, then update frames carrying binary deltas
Presence uses a distinct message type on the same socket so it can be dropped under load without affecting document integrity
REST: GET /documents/:id for the initial snapshot, GET /documents/:id/history, POST /documents/:id/restore
Every mutating REST call takes an idempotency key so a retry after a timeout cannot double-apply
The snapshot endpoint returns a state vector so the client requests only the deltas it is missing, not the whole document

Optimisations

Echo local keystrokes immediately and reconcile asynchronously — never wait for a server round trip to render a character
Coalesce remote presence updates into a single requestAnimationFrame batch; 50 users typing produces far more messages than frames
Virtualize the document so only visible blocks are in the DOM, keeping node count bounded on a 100k-word file
Compact the CRDT history periodically, otherwise document size grows monotonically with edit count
Debounce the IndexedDB write so persistence does not run on every keystroke
Send presence over an unreliable path conceptually: if a cursor frame is dropped the next one corrects it, so no retry logic is needed

Failure Modes

The half of the answer most candidates skip entirely.

Naming how the system breaks, and what the user sees when it does, is the cheapest way to signal production experience. Work through these before the interviewer has to ask.

WebSocket drops mid-edit: buffer local ops in IndexedDB, show a subtle reconnecting indicator, replay on resume
Reconnect after a long offline window: exchange state vectors first so you sync a delta rather than a full document
Server rejects the document as too large: fall back to read-only and surface an explicit export action
Presence channel saturated by a large meeting: shed presence messages first, since document integrity does not depend on them
CRDT library version skew between an old cached tab and a new deploy: version the wire format and force a reload on mismatch
A malicious client sends malformed deltas: validate on the server before fan-out, because CRDTs converge on garbage just as happily as on valid input

Handling Pushback

The interviewer will challenge you. Rehearse the concession, not just the defence.

Interviewer

Why not just use operational transforms? That is what Google Docs actually does.

Model response

OT is a legitimate choice and it produces smaller payloads, which matters at Google's scale. The cost is that OT requires a central authoritative server to transform every operation against concurrent history, so the correctness burden lives in a service my team may not own. A CRDT moves convergence into the client library, which means peer-to-peer and offline both work without extra server logic. If we already had an OT server and an team maintaining it, I would use it. Building fresh, I take the CRDT and pay for it in metadata size.

Interviewer

Your CRDT document grows forever. That seems like a serious problem.

Model response

It is a real cost and I would not hide it. Yjs keeps tombstones for deleted content so concurrent deletes converge. Mitigation is periodic compaction: snapshot the materialized document server-side, then garbage-collect history older than the snapshot. We lose fine-grained history before the snapshot point, which is why I would keep coarse version snapshots separately. The trade is bounded storage for reduced undo depth on old edits, and I would confirm with product that this is acceptable.

Interviewer

Do you really need three state layers? That sounds over-engineered for an editor.

Model response

The separation is what lets me degrade correctly. If presence and document share a channel and a lifecycle, a presence storm during a large meeting can back-pressure real edits, and a crashed tab leaves a ghost cursor that needs manual cleanup. Splitting them means I can drop presence messages under load with zero correctness impact. If the requirement were five concurrent editors and no offline support I would collapse this and just broadcast whole-document state, and I would say so.

Interviewer

What happens if two people apply conflicting formatting to the same word at the same instant?

Model response

The CRDT will converge deterministically, but converged is not the same as correct-looking. Both marks apply, so a word bolded by one user and italicized by another ends up bold-italic, which is usually what people expect. Where it gets ugly is competing values on the same attribute, like two different heading levels. There the CRDT picks a winner by clientId ordering, which is arbitrary from the user's perspective. I would make attribute conflicts visible rather than silent, and for high-stakes structural changes I would consider a short-lived lock on the block.

What Raises the Grade

Specific signals an interviewer is listening for on this prompt.

Signals

Separating durability requirements per state layer instead of treating all realtime state the same
Walking the reconnect sequence concretely rather than saying the client resyncs
Naming the CRDT metadata growth cost unprompted and proposing compaction
Choosing a degradation path (read-only plus export) rather than assuming the socket stays up
Framing the CRDT-versus-OT decision around team ownership and operational burden, not just algorithmic elegance

Study these chapters first

Next Steps

Turn one attempt into retained skill.

Attempt the drill cold a second time in three days — recall beats rereading
Record yourself on the pushback section; that is where most answers wobble
Run the related chapters above for any area where you had to guess
Finish with a 60-minute cross-topic staff mock to practise switching contexts

← All design drills

Staff · 45 min

Collaborative Document Editor

Also asked as: Google Docs, Notion, Confluence, Dropbox Paper.

The Prompt

Read it once, then start the timer and work without scrolling.

Design the frontend for a collaborative rich-text editor where multiple people edit the same document at the same time and see each other's cursors.

Everything below is a model answer. You will get far more out of this drill by attempting it cold first — set the timer, talk through it out loud, and only then compare.

Rehearse with Timer

A 45-minute phase plan you can practise against a clock.

Interactive · Drill rehearsal timer

Clarify and scope

6:00

Pin down concurrent editor count and offline expectations first — they drive every later decision
Explicitly descope what you will not design: auth, billing, mobile native, the storage backend
State the one thing you consider the crux: conflict resolution on a shared mutable structure

Requirements

What you should establish before drawing a single box.

Clarifying questions

How many concurrent editors per document — 5, or 500? That decides whether presence can be a simple broadcast or needs fan-out infrastructure.
Is offline editing required, or is a read-only degraded mode acceptable when the socket drops?
Do we need the full formatting surface, or is this plain text with comments? Rich text is what forces CRDT/OT rather than naive last-write-wins.
Is there a hard requirement that no edit is ever lost, or is a conflict banner acceptable in rare cases?
Who owns the merge algorithm — are we adopting Yjs or Automerge, or is the backend team building it?

Functional

Multiple users edit the same document concurrently with sub-second convergence
Live presence: remote cursors, selections, and participant avatars
Formatting (bold, headings, lists) that survives concurrent edits
Comments anchored to text ranges that survive edits to surrounding text
Document history with the ability to restore a prior version

Non-functional

Local keystroke echo under 16ms so typing never feels laggy
Remote edits visible within roughly 200ms on a healthy connection
No lost edits across a reconnect, including a 30-second offline window
Documents up to ~100k words without editor jank
Graceful read-only degradation rather than a blank screen when realtime fails

Model Answer

Architecture, data, interfaces, and optimisations — the RADIO body.

Architecture

Three-layer state model: document (durable, convergent), presence (ephemeral, lossy), local UI (never synced)
A CRDT document store (Yjs) as the single source of truth in the client, with the editor view rendered from it
An editor binding layer (ProseMirror or Lexical) that translates DOM events into CRDT transactions rather than mutating the DOM directly
A WebSocket provider that ships CRDT updates as binary deltas, not full document snapshots
An IndexedDB persistence provider so a reload or a disconnect never loses local work
A separate presence channel with a shorter TTL so a crashed tab's cursor disappears without manual cleanup

Data model

Document is a CRDT tree (Y.XmlFragment) rather than a plain string, so concurrent inserts at the same index both survive
Each edit is a delta keyed by (clientId, clock) — this pair is what makes operations idempotent on replay
Comments store a relative position (CRDT-anchored) rather than an absolute character offset, so they do not drift when text above them changes
Presence records are {clientId, userId, cursorAnchor, selectionHead, color, lastSeenAt} with a TTL of a few seconds
Version history stores periodic snapshots plus the delta log between them, because replaying all deltas from zero gets slow

Interfaces and contracts

WebSocket messages: sync-step-1 / sync-step-2 for initial handshake, then update frames carrying binary deltas
Presence uses a distinct message type on the same socket so it can be dropped under load without affecting document integrity
REST: GET /documents/:id for the initial snapshot, GET /documents/:id/history, POST /documents/:id/restore
Every mutating REST call takes an idempotency key so a retry after a timeout cannot double-apply
The snapshot endpoint returns a state vector so the client requests only the deltas it is missing, not the whole document

Optimisations

Echo local keystrokes immediately and reconcile asynchronously — never wait for a server round trip to render a character
Coalesce remote presence updates into a single requestAnimationFrame batch; 50 users typing produces far more messages than frames
Virtualize the document so only visible blocks are in the DOM, keeping node count bounded on a 100k-word file
Compact the CRDT history periodically, otherwise document size grows monotonically with edit count
Debounce the IndexedDB write so persistence does not run on every keystroke
Send presence over an unreliable path conceptually: if a cursor frame is dropped the next one corrects it, so no retry logic is needed

Failure Modes

The half of the answer most candidates skip entirely.

Naming how the system breaks, and what the user sees when it does, is the cheapest way to signal production experience. Work through these before the interviewer has to ask.

WebSocket drops mid-edit: buffer local ops in IndexedDB, show a subtle reconnecting indicator, replay on resume
Reconnect after a long offline window: exchange state vectors first so you sync a delta rather than a full document
Server rejects the document as too large: fall back to read-only and surface an explicit export action
Presence channel saturated by a large meeting: shed presence messages first, since document integrity does not depend on them
CRDT library version skew between an old cached tab and a new deploy: version the wire format and force a reload on mismatch
A malicious client sends malformed deltas: validate on the server before fan-out, because CRDTs converge on garbage just as happily as on valid input

Handling Pushback

The interviewer will challenge you. Rehearse the concession, not just the defence.

Interviewer

Why not just use operational transforms? That is what Google Docs actually does.

Model response

Interviewer

Your CRDT document grows forever. That seems like a serious problem.

Model response

Interviewer

Do you really need three state layers? That sounds over-engineered for an editor.

Model response

Interviewer

What happens if two people apply conflicting formatting to the same word at the same instant?

Model response

What Raises the Grade

Specific signals an interviewer is listening for on this prompt.

Signals

Separating durability requirements per state layer instead of treating all realtime state the same
Walking the reconnect sequence concretely rather than saying the client resyncs
Naming the CRDT metadata growth cost unprompted and proposing compaction
Choosing a degradation path (read-only plus export) rather than assuming the socket stays up
Framing the CRDT-versus-OT decision around team ownership and operational burden, not just algorithmic elegance

Study these chapters first

Next Steps

Turn one attempt into retained skill.

Attempt the drill cold a second time in three days — recall beats rereading
Record yourself on the pushback section; that is where most answers wobble
Run the related chapters above for any area where you had to guess
Finish with a 60-minute cross-topic staff mock to practise switching contexts