Design Google Docs

Expert60 min
1 / 30
understanding•6 min read

Problem Statement & Context

How Problem Statement & Context shapes architecture and interviewer follow-ups for Design Google Docs.

Problem Statement & Context

Google Docs is a browser-native collaborative word processor where multiple editors mutate the same logical document concurrently. The interview tests whether you can defend operation-based concurrency (OT or CRDT), not naive last-write-wins on JSON blobs.

Why this is harder than chat

Chat appends immutable events; docs rewrite overlapping ranges. Two users typing in the same paragraph create intent-preserving transforms or mergeable structures. Servers must assign stable revision ids, broadcast ops with causality, and compact history without breaking offline replay.

Scale anchors (state explicitly)

Assume 2B+ Workspace users, tens of millions of concurrent editing sessions, and peak hundreds of thousands of ops/sec on celebrity docs (all-hands notes). Name SLOs: keystroke fanout p99 < 150ms within region, durable commit before ack, export job p95 < 30s for 50-page docs.

Who we are designing for

  • Individual editor: one writer, comments, and a shareable link — the latency floor that everyone else inherits.
  • Enterprise tenant: domain sharing policies, data-loss prevention, audit trails, and retention holds layered on top of the same edit path.
  • Power user: edits made offline on a flight that must merge cleanly on reconnect, version restore, and suggestion (track-changes) mode.
pythonOne Dark Pro
1def catch_up_ops(last_rev: int, head_rev: int, limit: int = 500) -> range:
2    start = last_rev + 1
3    end = min(head_rev, last_rev + limit)
4    return range(start, end + 1) if end >= start else range(0)

The failure story that frames the design

Consider an editor who makes 40 edits offline on a flight, then reconnects. A naive design replays those queued ops against the current head revision and corrupts the document, because the offline positions point at text that other people have since deleted or shifted. The correct design transforms each queued op against everything that committed while the client was gone, using the revision id the client last saw as the causal anchor. Hold this scenario in mind throughout: the durable op log, the monotonic revision ids, the transformation step, and history compaction all exist to make that one reconnect converge correctly.

Key Highlights

  • •Reconcile concurrent overlapping edits with OT or CRDTs — last-write-wins silently drops keystrokes
  • •Separate soft presence/cursor awareness from durable text commits; they have opposite consistency needs
  • •Derive SLOs from scale: keystroke fanout p99 < 150ms in-region, export p95 < 30s for 50 pages
  • •Offline edits transform against everything committed while disconnected, anchored on the last-seen revision id
Interviewer signal
When discussing Problem Statement & Context, cite server_rev monotonicity and OT boundary conditions.
Delivery tip
Quantify assumptions before drawing services — interviewers reward arithmetic.

Section Rescue Kit

Buzzwords to use:

OpLog-1Awareness-1

Safe statements:

  • "I will not sacrifice acknowledged text durability to save presence bandwidth."
  • "If time is short, I defer export polish before OT correctness."
Design Google Docs - System Design | WinJob | WinJob