Design a Real-Time Collaborative Document Editor With Version History

Design a browser-based document editor, comparable to Google Docs, in which several people can open the same document and type into it at the same time, each seeing the others' edits within moments. The source lists this prompt without describing how the conversation went, so the scope below is the standard one for this problem, stated as assumptions. The parts follow the order an interviewer usually pushes through. ### Constraints and Clarifications - Assume rich-text documents (paragraphs, headings, lists, basic formatting) that owners can share with other users as editors or viewers. - Most documents have one or a few people editing at once, but the design must also cope with a popular document that has dozens of simultaneous editors and many more viewers. - Edits must converge: when everyone stops typing, every participant sees exactly the same document. - Offline editing, comments and suggestion mode are out of scope unless the interviewer brings them in. ### Clarifying Questions - How many simultaneous editors should one document support, and how quickly should a remote keystroke appear for others? - Is offline editing with a later merge required, or can the client assume a live connection while editing? - Is full version history with restore required, or only durability of the latest content? - Are presence indicators (who is viewing, where each cursor is) part of the core requirements? ### Part 1 — Requirements and high-level architecture List the functional and non-functional requirements, then sketch the main components: how clients connect, where the live editing session for a document runs, and where document content is stored. ```hint Where a session lives Consider whether every edit to one document should pass through the same server process, and what that buys you when edits collide. ``` #### What This Part Should Cover - Functional scope (create, share, concurrent editing, history) separated from non-goals - Latency, convergence and durability targets that drive later choices - A persistent two-way connection and a clear owner for each live document - Storage split between a record of edits and periodic document snapshots ### Part 2 — Resolving concurrent edits Two users insert text at the same position at the same moment, while a third user deletes the paragraph that contains that position. Explain how the system guarantees that every client ends up with the same document and that nobody's typing is silently lost. ```hint Positions move An edit is expressed against the version of the document its author was looking at. By the time it reaches the server, other edits may have shifted what that position refers to. ``` #### What This Part Should Cover - A concrete conflict-resolution technique and how it adjusts or identifies positions - How a client stays responsive by showing its own edits before the server confirms them - An ordering or versioning scheme that every client agrees on - Trade-offs between a server-ordered approach and a fully decentralized one ### Part 3 — Persistence, history and scale Describe how edits are stored durably, how a user who opens or reconnects to a document gets the current content quickly, how version history and restore work, and how the system scales to many documents and to one very busy document. ```hint Replaying from the beginning Think about what a newly joining user would have to do if the only record were every edit since the document was created. ``` #### What This Part Should Cover - A durable write path that persists an edit before confirming it - Snapshots and compaction alongside the edit record - Catch-up and reconnection from a known version without duplicating edits - Partitioning by document, handling a hot document, and recovering when a session server dies ### What a Strong Answer Covers - Requirements that justify a single ordering point per document - A correct, clearly explained convergence mechanism, not last-writer-wins on whole documents - No acknowledged edit lost when a server fails, and no edit applied twice after a reconnect - Presence and cursors treated as short-lived state, separate from document content - Permissions enforced when joining a session and on every submitted edit ### Follow-up Questions - How would you support offline editing, where a user edits for an hour without a connection and then reconnects? - How would you anchor a comment to a range of text so that it stays attached through later edits? - A document has 200 simultaneous editors and its session server is saturated. What do you change? - How would you move a live session to another server during a deploy without users noticing?