Design a Google Docs-Style Real-Time Collaborative Editing Backend

Design the backend of a collaborative document editor like Google Docs. Several users can open the same document at once and edit it in real time. Each user sees the others' changes and cursors within moments, every user's copy ends up with the same content, and the document is saved durably with a revision history. The interviewer wants depth on real-time collaboration and on the backend architecture that supports it. Control-plane flows, for example account management, document creation and sharing settings, need only a brief mention. ```hint Two edits at the same spot Two users edit the same position at the same moment, each starting from the same version of the text. Decide what makes both screens end up with the same result, and where that logic runs. ``` ```hint One place per document Consider whether all editors of one document should be served by the same server process, and what that buys and costs you. ``` ```hint Opening a document with a long history Decide what you persist on every edit, and how a document with years of edits can still open quickly. ``` ### Constraints and Clarifications - Assume a text document. Rich-text formatting can be modeled as attributes on ranges of characters, so the core discussion can treat the document as a sequence of characters. - Assume a user's own typing appears on their screen immediately, without waiting for the server. ### Clarifying Questions - How many people edit one document at the same time in the common case, and in the worst case? How many documents are open at once? - How quickly must a collaborator see an edit? - Must editing keep working offline, with changes merged on reconnect? - Are comments, suggestion mode and revision history in scope? - Can a user lose their last moment of typing if a server crashes, or must every acknowledged edit survive? ### What a Strong Answer Covers - A concrete concurrency-control model for simultaneous edits, with convergence shown on two conflicting edits - Where each document's live state is held, how clients reach it, and how one ordering of edits is established - What is persisted on each edit, how a long-lived document still opens quickly, and how revision history is served - Behavior on reconnect, on duplicate or missed edits, and when the server holding a document's live state crashes - Scaling across many documents, and for a single document with many collaborators - Presence and cursors handled separately from document content, and access checks on connect and on each edit, kept brief ### Follow-up Questions - A user edits offline for an hour and then reconnects. How are their edits merged, and what does it cost? - The server holding a document's live session crashes mid-edit. What do clients see, and why is no acknowledged edit lost? - How would the design change for one document with hundreds of simultaneous editors and many more viewers? - How would you implement "restore this version" without rewriting the history?