Design a Real-Time Collaborative Document Editor with Concurrent Editing

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. ```hint 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 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. ``` ### 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? ### What a Strong Answer Covers - A concrete concurrency-control choice (operational transformation or a CRDT), why it converges, how ties at the same position are broken, and why simpler options such as locking or last-write-wins fail - A real-time path with per-document ordering: how connections reach the component that sequences a document's edits, and when an edit is acknowledged relative to it being made durable - Storage built from an append-only edit log plus periodic snapshots, and how that yields fast document loads, version history and restore - Presence and cursors treated as ephemeral data, kept separate from durable edits - Permission checks on connect and on every edit, including revocation during a live session - Capacity reasoning that distinguishes the many-documents problem from the single hot document with many editors - Failure handling: reconnect and resubmission without duplicate edits, sequencer crash and takeover without forked history, divergence detection, and observability ### 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?