Google Docs

Collaborative Editing

Design a document editor where many people type in the same document at once, see each other's changes within a moment, and always end up with the same text.

Overview

A collaborative editor lets several people type in one document at the same moment. Each person sees their own keystrokes instantly, sees other people's changes within a fraction of a second, and, when everyone stops, every copy holds exactly the same text.

The hard part is that changes cross the network while people keep typing. If Ana inserts a word at position 10 while Ben deletes a sentence before it, Ana's position 10 means something different on Ben's screen. Sending whole document versions and diffing them guesses wrong in exactly these cases; locking paragraphs avoids the problem by making collaboration worse. The standard answer for text is operational transformation (OT): send small changes, and shift each incoming change past the edits the receiver already has. Google described this model for Docs in 2010.

This page is the design problem: the servers, the protocol, storage and scale. The Real-Time Collaboration and CRDT topics cover the two merge families in depth; here they appear only as far as the design needs them.

Questions to ask first

Plain text or rich text? — Rich text, but the merge is explained on inserts and deletes; styles follow the same rules
How many editors on one document? — Usually one or two; up to about 100 at once
How fast must others see a change? — Under 500 ms at p99 in the same region (a target we chose)
Offline editing? — Short gaps (a flaky connection) must merge cleanly; long offline work is a stretch goal
Version history? — Yes: browse and restore earlier versions
Scale? — 5 million documents open at peak, about 1.2 editors each

What you will be able to do

Explain why concurrent text edits need transformation, and walk through one by hand.
Describe the client-server protocol: local apply, one change in flight, server ordering, acknowledgment.
Store a document as a revision log plus snapshots, and load it quickly.
Route every editor of a document to one server, and say what happens when that server dies.
Compare OT with CRDTs and with Figma's server-ordered last-writer-wins.

Key concepts

Operational transformation
Revision log
Optimistic local apply
One sent change at a time
Per-document sequencer
Snapshots
CRDT
Presence
Sticky routing

Functional requirements

Several editors change the same document at once
Each editor sees their own typing immediately and others' changes shortly after
All copies converge to the same text
Show other editors' cursors and who is present
Browse and restore earlier versions
Share with viewer, commenter and editor roles

Non-functional requirements

Local keystrokes never wait for the network
Others see a change within 500 ms at p99 in the same region (a target we chose)
No acknowledged change is ever lost
Up to about 100 simultaneous editors on one document (an assumption)
A viewer can never change the document, even with a modified client

Interview questions

Walk me through what happens when two people type at the same time.
Why not just lock the paragraph someone is editing?
Why does every editor of a document connect to the same server?
OT or CRDT?
How do you store a document and load it fast?
How does version history work?
What happens when the session server crashes?
How do you enforce permissions?