System Design Arena
Design Google Docs
Collaborative document editing: operational transformation vs CRDTs, presence, permissions, and version history for millions of concurrent documents.
Case Study
Google Docs
Same conversation, diagrams, and wrap-up you expect—now framed with clearer scaffolding and iconography.
Prompt
Design a collaborative editor like Google Docs where multiple people edit the same document simultaneously and every participant converges to the same text.
Interview snapshot
- • Topic: Google Docs
- • Expected depth: 45 - 60 minutes
- • Focus areas: APIs, scale estimation, resilient architecture
- • Wrap-up: risk, monitoring, disaster recovery
Key takeaways
- • Multiple users edit the same document with live character-level updates.
- • Local edits render instantly (<16ms); remote edits <200ms.
- • WebSocket per open doc: submit {baseVersion, ops[]}, receive {version, ops[], authorId}.
🎙️ Interview mode
Practice this like a real interview
Don't read the answer first. Work the framework against the bare prompt, then compare against what the interviewer expected at each step.
Scorecard
What the interviewer is evaluating
Staff-level signal
Can the candidate demonstrate the concurrent-edit conflict with a concrete example, then choose OT-with-a-sequencer or CRDT with an articulated trade-off?
🧠 Staff engineer judgment
Do not shard a single document — one doc’s edit rate is human-bounded. Centralize per doc (sequencer), shard across docs. Complexity budget goes to convergence, not to distributing 500 ops/sec.
Calibration
The common (bad) answer
Editor autosaves doc every 2s → PUT /doc Last write wins
❌ Why this scores poorly: Two concurrent editors overwrite each other’s paragraphs on every save. LWW on whole documents is data loss with a save button.
✓ What a strong answer adds
- Character-level operations, not document blobs.
- A per-doc sequencer totally orders ops; OT transforms concurrent ones.
- Show convergence with a concrete two-user example.
- Op log + snapshots: storage, history, and offline merge from one mechanism.
- Presence as soft state over the same WebSocket.
Video walkthrough
Real-Time Collaboration Explained
Hello Interview · 15 min
OT vs CRDT explained clearly — the single decision this interview turns on.
Work the prompt yourself first — guided practice grades your own answer step by step. Watching someone else design it feels like progress and teaches you far less.
Interview flow
Dialogue timeline
Interviewer
What's the core challenge here?
Candidate
Concurrent edits to the same text. Two users insert at position 5 simultaneously — naive last-write-wins corrupts the document. We need every replica to converge to the same result while feeling instant locally.
Interviewer
What are the two standard approaches?
Candidate
Operational Transformation — transform incoming operations against concurrent ones, with a central server ordering them — and CRDTs, where characters carry identities so merges commute without a central authority. Docs-style products classically use OT with a server as sequencer; I'll design that and note the CRDT trade.
Interviewer
Walk me through OT with a concrete example.
Candidate
Doc is 'cat'. A inserts 'X' at 0; B deletes position 2 concurrently. Server orders A first; B's delete arrives referencing old positions, so it's transformed: shift by A's insert → delete position 3. Both replicas apply operations in server order with transforms and converge to 'Xca'.
Interviewer
Why does a central server per document help so much?
Candidate
One sequencer per doc gives a total order of ops — the transform matrix stays simple (op vs op), versions are just sequence numbers, and history is the op log itself. The cost: that doc's edits all route to one place — fine, because a single doc's edit rate is human-scale.
Interviewer
How do sessions and presence work?
Candidate
Every open doc holds a WebSocket to the doc's session server (consistent-hash docId → server). The server broadcasts ops, cursors, and selections. Presence is soft state — lost on reconnect, rebuilt instantly.
Interviewer
Offline edits for an hour, then reconnect.
Candidate
The client queued local ops against version V. On reconnect it pulls ops V..now, transforms its queue over them (same OT machinery), and submits. Convergence logic is identical to live editing — offline is just a long network delay.
Interviewer
Storage and history?
Candidate
Append-only op log per doc + periodic snapshots so loading is snapshot+tail, not a million-op replay. Named versions are pointers into the log; 'see edit history' falls out for free.
Interviewer
Scale check: millions of concurrent documents.
Candidate
Each doc is small and independent — shard by docId across session servers. The hard scaling is ops/doc (bounded by humans) not docs (unbounded but parallel). Hot doc with 100 editors: broadcast fan-out 100 — still trivial. The design scales because docs don't interact.
Scoping
Requirements & trade-offs
Functional Requirements
- —Multiple users edit the same document with live character-level updates.
- —Cursors/selections of collaborators visible in real time.
- —Offline editing with safe merge on reconnect.
- —Version history with restore. Out of scope: comments, suggestions.
Non-Functional Requirements
- —Local edits render instantly (<16ms); remote edits <200ms.
- —Strong eventual convergence — all replicas end identical, no lost edits.
- —A document survives server crashes with zero committed-op loss.
- —Millions of concurrent docs; hundreds of editors per doc worst-case.
Blueprint
Architecture modules
Module 1
Protocol & API
- •WebSocket per open doc: submit {baseVersion, ops[]}, receive {version, ops[], authorId}.
- •Ops: insert(pos, chars) / delete(pos, len) — transformed server-side.
- •REST: snapshots, history list, permission grants.
- •ACL check on session open + every op batch.
Module 2
Back-of-the-Envelope
- •Typing ≈ 5 ops/sec/user; 100 editors → 500 ops/sec/doc max — tiny per doc.
- •10M concurrent docs × avg 2 sessions → 20M WebSockets → ~200 session servers.
- •Op ~50 bytes; a heavily-edited doc's log ~10MB/year → snapshot every ~1K ops.
- •Doc-to-server mapping via consistent hashing; failover re-homes doc with log replay.
Module 3
System Diagram Notes
- •Client ↔ Session server (per-doc sequencer, OT transform) ↔ Op log + snapshots.
- •Presence broadcast in-memory on session server.
- •Cold docs hydrate from snapshot+tail; LRU eviction of idle docs.
- •Permissions service consulted at session open; cached with invalidation.
Module 4
Design Playbook
- •Demonstrate the conflict with a two-user example before naming OT — show, then tell.
- •OT vs CRDT in three sentences, then commit with a reason.
- •Per-doc sequencer: centralize where cheap (one doc), shard where needed (all docs).
- •Offline = long-latency online; same transform path — say it explicitly.
- •Snapshot + op-log gives history free; interviewers reward noticing that.