Problem and Scope
Design a collaborative text editor similar to Google Docs that allows multiple users to edit the same document simultaneously in real-time.
Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Users should be able to see changes made by other users in real-time
- Multiple users should be able to edit the same document concurrently
- All users' views should eventually converge to the same document state
- Support for basic text operations (insert, delete, format)
- Changes should be propagated to all users quickly, ideally within milliseconds
- Users should be able to edit any part of the document at any time
Non-functional requirements:
- Low latency for propagating changes (ideally less than 100ms)
- Scalability to support thousands of concurrent users on popular documents
- Reliability so that no edits are lost
- Consistent document state across all clients
- Efficient bandwidth usage (avoid sending entire documents for small changes)
- Support for offline editing and syncing when reconnected
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- Support for billions of users and documents
- Ability to handle thousands of users editing a single document concurrently
- Document sizes ranging from a few KB to several MB (hundreds of pages)
- Global user base with potential for high network latency between users
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- Client-side editor interface
- Mechanism for transmitting changes between clients
- Server architecture for coordinating changes
- Conflict resolution strategy
- Persistence layer for document storage
- Operational transformation or CRDT implementation
- Real-time communication protocol
- Maintaining consistency across all clients while allowing concurrent edits
- Handling network latency and disconnections
- Efficient conflict resolution without requiring locks
- Scaling to support thousands of concurrent editors
- Managing the order of operations when they arrive out of sequence
- Providing a responsive user experience even under challenging network conditions
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How would your design handle conflict resolution when multiple users edit the same section simultaneously?
- Focus: Assess the candidate's answer to "How would your design handle conflict resolution when multiple users edit the same section simultaneously" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What are the trade-offs between operational transformation and CRDTs for collaborative editing?
- Focus: Assess the candidate's answer to "What are the trade-offs between operational transformation and CRDTs for collaborative editing" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your design handle network partitions or users temporarily going offline?
- Focus: Assess the candidate's answer to "How would your design handle network partitions or users temporarily going offline" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- Can you explain your approach to scaling when thousands of users are editing the same document?
- Focus: Assess the candidate's answer to "Can you explain your approach to scaling when thousands of users are editing the same document" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What data structure would you use to represent the document on the client side?
- Focus: Assess the candidate's answer to "What data structure would you use to represent the document on the client side" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your system handle document versioning or history?
- Focus: Assess the candidate's answer to "How would your system handle document versioning or history" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to see changes made by other users in real-time; Multiple users should be able to edit the same document concurrently; All users' views should eventually converge to the same document state. Establishes the constraints that materially affect Design Google Docs, including Low latency for propagating changes (ideally less than 100ms); Scalability to support thousands of concurrent users on popular documents. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Client-side editor interface; Mechanism for transmitting changes between clients; Server architecture for coordinating changes; Conflict resolution strategy. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as Support for billions of users and documents; Ability to handle thousands of users editing a single document concurrently to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Persistence layer for document storage. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Maintaining consistency across all clients while allowing concurrent edits; Reliability so that no edits are lost; Consistent document state across all clients. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Scaling to support thousands of concurrent editors; Managing the order of operations when they arrive out of sequence; Providing a responsive user experience even under challenging network conditions. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.