A real-time collaborative editor
Design a Collaborative Editor (Google Docs), from a blank page
This is how the interview actually runs: one prompt, and you decide what to cover and in what order. Write each section, then compare it with a reference design and see what you left out.
A 45-minute round. You drive; nothing prompts you.
The prompt
You are building the editor for a team documentation product: engineering specs, meeting notes, incident write-ups. Documents are structured text, typically 5-50 KB and occasionally a couple of megabytes. Usually one to five people edit a document together; the company all-hands doc has thirty editors and two hundred people watching.
Users expect to see each other's keystrokes within a fraction of a second, along with live cursors and avatars. They also edit on trains, close laptop lids mid-sentence, and leave tabs open for a week.
The prototype sends the whole document to the server a second after each change, and the server keeps whichever copy arrived last. In testing, two people typing at once kept losing each other's sentences.
What the interviewer would tell you if you asked
- About 50,000 documents edited per day and 20,000 concurrent connections at peak; most documents have at most five editors at once.
- An active typist generates 5-10 operations per second; at any moment roughly a tenth of connected users are typing.
- Servers run behind a load balancer that supports WebSockets and drains connections for up to 30 s during daily deploys.
- Postgres, Redis and object storage are available.
- Messages on a single WebSocket connection arrive in order, but connections drop without warning.
- Clients may reconnect to a different server than before, with arbitrarily stale state.
- Users are authenticated and per-document permissions are checked on connect.
- Client clocks are unreliable and are not used for ordering.
01
about 5 minWhat does the system have to do, and how well? List the functional requirements, then the non-functional ones (latency, availability, consistency, scale), and the questions you would ask the interviewer.
02
about 5 minTurn the volumes into the numbers that drive the design: requests per second at peak, storage, bandwidth, and anything else that decides whether one machine is enough.
03
about 10 minName the components and what each one is responsible for. Then trace the main request through them, and say where the durable state lives.
04
about 15 minPick the hardest decisions in this design and make them: what you chose, what you rejected, and which constraint decided it.
05
about 10 minWhat breaks? Walk through crashes, duplicates, slow dependencies and overload, and what the design does in each. Then: what changes at ten times the load, or with a new requirement?
Write something in at least 3 sections first. Gaps are fine; the comparison shows what they cost.