A real-time collaborative editor

Design a Collaborative Editor (Google Docs)

Many people edit the same document at once over unreliable connections. Every client must converge on the same text, no acknowledged keystroke may be lost, and daily deploys must not kick anyone out.

Advanced, about 60 minutes, 12 stages

Start the investigation Design it from a blank page See the full walkthrough

The situation

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 it has to do

Functional

Several users edit the same document concurrently and see each other's changes live.
Users see who else is in the document and where their cursors are.
Edits made offline, for minutes or hours, merge when the client reconnects.
Users can browse and restore earlier versions.
Documents open quickly even after years of edits.

Non-functional

All clients converge on identical content once they have received the same edits.
No acknowledged edit is ever lost.
Remote edits appear within about 200 ms on decent connections.
Deploying servers loses no edits and does not force a reload.
One slow or misbehaving client cannot degrade a session for everyone else.

Constraints and assumptions

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.

Interview questions it prepares you for

“Design Google Docs.”
“Design a multiplayer whiteboard or Figma-like editor.”
“How would you add live presence and cursors to an existing app?”
“Design a chat system that works offline and syncs when reconnected.”
“Your WebSocket servers need to be redeployed daily. How do you do it without disrupting users?”

Read and practise next

How Figma built it · Real-time multiplayer editing, in their engineers' own words

Concepts to know first: Persistent connections, Ordering.