Design a collaborative document editor
hardComplete guide with examples and interview questions · 50 min
Say it out loud in an interview — clear, simple, no textbook wording.
If someone asks me to design a collaborative editor, I would say it is a text document that several people edit at once, where every client converges to the same text no matter what order edits arrive in. The editor itself is the easy part. The merge story is the whole question.
Interviewers care because this is the hardest realtime problem in frontend interviews, and it separates candidates who have thought about concurrency from candidates who have only built forms. The answer is not a library name. It is the reasoning about why concurrent edits need help to converge.
The senior nuance is that typing must never wait for the network. Local edits apply instantly, sync happens in the background, and remote edits merge in without moving the local caret to a surprising place. Responsiveness is a correctness requirement here, not polish.
Key takeaways
- •Shared editing means concurrent operations, and concurrent operations need a merge story
- •CRDTs merge by construction, OT transforms against history: pick one and say why
- •Presence (cursors, selections) is separate from document state and far more ephemeral
- •Every keystroke is not a network event: batch, debounce, and compress local edits
- •Undo in a shared document is a design decision, not a free feature
Track your mastery
Sign in to save Q&A scores, coding challenge progress, points, and streaks across devices.
Sign in to save progress