How would you design a collaborative editor like Google Docs?
481 views
85 of 106
1
The problem
Question presented to candidate:
"Design a collaborative document editor like Google Docs. Several people type in the same document at the same time and everyone sees everyone else's changes within a fraction of a second, with cursors. Edits must never be lost, and everyone must end up with the same document. How does it work?"
What a strong answer should cover:
Why naive "send my edit position to everyone" diverges when edits are concurrent, and the goal: convergence while keeping each user's intent
Operational transformation (OT): a central server orders operations into a revision log and transforms each incoming op against the ops it has not seen; clients keep one pending op and transform incoming ops against it
CRDTs: every character gets a unique id, inserts reference neighbours by id, deletes leave tombstones, so replicas converge in any delivery order (good for offline and peer-to-peer) at a metadata cost
Architecture: WebSocket to a per-document session server (all editors of one doc on one owner), durable op log plus periodic snapshots, presence and cursors on a separate lossy channel
Capacity and limits: ops per second, log growth, editors per document; what breaks at 10x
Clarifying questions expected:
Plain text or rich text with formatting, tables and comments? Is offline editing required?
How many concurrent editors per document, and how many open documents at peak?
Do we need version history and named versions?
Code / implementation expected: Optional โ the design; the example shows naive replay diverging, server-ordered OT converging, and a CRDT converging in every delivery order.
collaboration
crdt
real-time
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Developers preparing for system design interviews. You know what a WebSocket and a database log are; OT and CRDTs are explained from scratch.
Difficulty: Hard
Verified with: Node 22.22, Python 3.12, Go 1.24 and Java 21 (all four print identical output).
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the exact words an interviewer expects. All behaviour shown comes from running the example; the Verified section quotes the full output. Capacity numbers are worked from stated assumptions.
1. Why This Even Matters โ A Story First
Three friends edit a shopping list on three phones, offline on a train. The list says cat (someone's typo for "cats"). Alice inserts an h after the c, Bob deletes the c, and Carol adds an s at the end. Everyone means well: together t
The solution is hidden so you can try first
15 min read ยท 15 sections
4
Read the code
Collaborative editing: naive replay diverges, server-ordered OT converges, an RGA-style CRDT converges in all 120 orders