Design a Real-Time Collaborative Document Editor with Concurrent Edits

Design a collaborative document editor: several people open the same document, edit it at the same time, and see each other's changes in near real time. The interview is for a frontend engineer, so cover the client (how the editor models the document, applies local and remote edits, and shows other people's activity) as well as the backend that synchronizes edits between clients. ```hint Two edits at once Take two users who edit the same sentence at the same moment, starting from the same text. Decide what each of them should see afterwards, and what information you need so that both end up with the same document. ``` ```hint The first frame after a keystroke Decide what the user sees on their own screen the instant they type, before the server has heard about the edit, and what has to happen when the server's view arrives. ``` ### Constraints and Clarifications - Concurrent edits from different users must not be lost, and every client must end up with the same document once edits stop. - A user's own typing must appear immediately, without waiting for a round trip to the server. ### Clarifying Questions - Plain text or rich text (formatting, lists, tables, embedded objects)? - How many people edit one document at the same time, and how many documents are active at once? - Must editing work offline and merge when the user reconnects? - Which presence features are required: live cursors, selections, a list of who is viewing? - Is version history or restoring an earlier version required? - Which permission levels exist, for example view, comment and edit? ### What a Strong Answer Covers - A representation of edits as operations and a concrete conflict-resolution strategy, with a worked example of two concurrent edits - The client state model: optimistic local edits, edits not yet acknowledged, and how incoming remote edits are adjusted against them - The sync protocol and transport, including ordering, acknowledgements and reconnection - The server side: one authority per document, persistence as snapshots plus an operation log, and scaling across many documents - Presence and remote cursors, undo semantics and permissions - Failure handling and how divergence between clients is detected ### Follow-up Questions - Operational transformation or CRDTs: which would you choose for this product, and what would change on the client and on the server? - A user edits offline for an hour and then reconnects. Walk through what happens. - How should undo behave when other people have edited the same region since your change? - One document suddenly has hundreds of simultaneous editors. What breaks first, and how do you handle it?