Design a Real-Time Collaborative Document Editor with Concurrent Editing
MicrosoftSoftware Engineer · Other
Last updated
A senior-level system design prompt asking for a browser-based document editor where many people edit the same file at once, similar to Google Docs. It tests concurrency control for simultaneous edits, real-time sync, durable storage with version history, sharing permissions, and how the service scales and recovers from failures.
Design a browser-based document editor in which several people can work on the same document at the same time, similar to Google Docs. Each collaborator should see the others' changes appear within moments, every open copy of the document must end up with identical content, and no edit the system has acknowledged may ever be lost.
Only the product name was given, so the scope below is the usual one for this prompt. Treat it as a set of assumptions to confirm with the interviewer before you start designing:
- Users create rich-text documents (text plus formatting such as bold, headings and lists) and open them in a browser.
- Everyone with edit access can type into the same document concurrently, including at the same position.
- Collaborators can see who else has the document open and where their cursors and selections are.
- An owner shares a document with specific people as viewer, commenter or editor.
- Users can browse a document's version history and restore an earlier version.
- A client that briefly loses its connection keeps accepting local edits and catches up when it reconnects.
Cover the requirements, a rough capacity estimate, the main components and data model, how concurrent edits are ordered and merged, how documents and their history are stored, and how the system scales and recovers from failures.
Constraints and Clarifications
- This was asked in a senior-level loop: you are expected to drive the discussion, commit to an approach for concurrent editing, and defend it against the main alternative.
- No traffic, size or latency figures were given. Propose your own, label them as assumptions, and use them to size the system.
- Comment threads, spreadsheets, slides and search across documents are out of scope unless the interviewer brings them in.
Clarifying Questions
- How many people may edit one document at the same time, and how large can a single document grow?
- How long can a client stay disconnected: a few seconds of flaky Wi-Fi, or hours on a flight?
- How quickly should one person's edit appear for everyone else?
- How fine-grained does version history need to be, and how long is it retained?
- Does sharing include link-based or organization-wide access, and must revoking access take effect on a session that is already open?
Hints
Hint 1
Follow one keystroke: Trace a single inserted character from the moment it is typed until it appears on a collaborator's screen, then ask what has to happen when two people type at the same spot at the same instant.
Hint 2
Who decides the order: Decide which component, if any, has the final say on the order of concurrent edits to one document, and what that choice implies for routing connections and for surviving a crash.
Follow-up questions
- How does the design change when one document has hundreds of simultaneous editors and thousands of viewers?
- A user edits offline for several hours and then reconnects after others have rewritten the same section. What happens, and what would you change if long offline editing became a core requirement?
- How do you make undo reverse only the current user's own edits when others have typed since?
- How would you deploy a new version of the component that holds live document sessions without interrupting people mid-edit?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.