Design Google Docs: system design interview question

How the interviewer opens it

“Design a collaborative document editor like Google Docs. Multiple people should be able to edit the same document at the same time and see each other's changes and cursors live.”

The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.

What to clarify first

document scope
scale
read:write mix
collaboration limits
latency
consistency versus availability
durability and retention
disconnects
presence
permissions

The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.

Scope of a strong answer

Core requirements

Create and open shared text documents
Edit concurrently without losing nonconflicting changes
Show other participants and their live cursors
Save edits durably and recover from brief disconnections

Usually out of scope

Comments and suggestion workflows
Tables, spreadsheets, and embedded media
Building the browser's full editing and layout engine
Cross-region active-active editing

What interviewers probe

Concurrent edits and meaningful cursor positions: Clients edit different local versions, often with unacknowledged changes. Agreeing on message order does not make positional edits correct, and a raw cursor offset becomes wrong as other people insert or delete text.
Durable acknowledgments, reconnect, and owner failover: A client can lose an acknowledgment after its edit committed, and an editing owner can die between saving and broadcasting. Recovery must preserve one history without applying retries twice or leaving gaps around snapshots.
Room fanout, slow clients, and expendable presence: Edit traffic grows with the number of senders, but delivery grows with senders times recipients. Cursor traffic can exceed edit traffic, and one slow connection must not stall a shared document.

Common mistakes

Treating last-write-wins document replacement as collaborative editing.
Naming OT or CRDT without explaining one concrete concurrent-edit case.
Assuming a server-assigned order fixes stale positional operations.
Acknowledging edits from memory, or retrying without durable deduplication.
Treating cursor positions as timeless offsets and cursor events as durable edits.
Ignoring the snapshot-to-stream gap, stale owners, or unbounded queues during reconnect and failover.

The bar by level

Senior (L5/E5): Explains an end-to-end concurrency model including pending client edits, deterministic conflict handling, and cursor mapping. Defines durable acknowledgments, operation identity, snapshot-plus-tail recovery, and document ownership. Handles slow clients and room fanout with bounded resources and uses the workload estimates to choose partitioning.
Staff (L6+/E6+): States and defends invariants across the client, owner, log, and snapshots. Closes commit-before-broadcast and split-owner failure windows with replay, atomic persistence, and fencing. Defines safe compaction and stale-client behavior, weighs OT against CRDT for the stated offline requirements, and adapts ownership and fanout for regional or audience changes without overbuilding v1.

How the interviewer opens it

“Design a collaborative document editor like Google Docs. Multiple people should be able to edit the same document at the same time and see each other's changes and cursors live.”

The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.

Scope of a strong answer

Core requirements

Create and open shared text documents
Edit concurrently without losing nonconflicting changes
Show other participants and their live cursors
Save edits durably and recover from brief disconnections

Usually out of scope

Comments and suggestion workflows
Tables, spreadsheets, and embedded media
Building the browser's full editing and layout engine
Cross-region active-active editing

What interviewers probe

Concurrent edits and meaningful cursor positions

Clients edit different local versions, often with unacknowledged changes. Agreeing on message order does not make positional edits correct, and a raw cursor offset becomes wrong as other people insert or delete text.

Durable acknowledgments, reconnect, and owner failover

A client can lose an acknowledgment after its edit committed, and an editing owner can die between saving and broadcasting. Recovery must preserve one history without applying retries twice or leaving gaps around snapshots.

Room fanout, slow clients, and expendable presence

Edit traffic grows with the number of senders, but delivery grows with senders times recipients. Cursor traffic can exceed edit traffic, and one slow connection must not stall a shared document.

Common mistakes

Treating last-write-wins document replacement as collaborative editing.

Naming OT or CRDT without explaining one concrete concurrent-edit case.

Assuming a server-assigned order fixes stale positional operations.

Acknowledging edits from memory, or retrying without durable deduplication.

Treating cursor positions as timeless offsets and cursor events as durable edits.

Ignoring the snapshot-to-stream gap, stale owners, or unbounded queues during reconnect and failover.

The bar by level

Senior (L5/E5)

Explains an end-to-end concurrency model including pending client edits, deterministic conflict handling, and cursor mapping. Defines durable acknowledgments, operation identity, snapshot-plus-tail recovery, and document ownership. Handles slow clients and room fanout with bounded resources and uses the workload estimates to choose partitioning.

Staff (L6+/E6+)

States and defends invariants across the client, owner, log, and snapshots. Closes commit-before-broadcast and split-owner failure windows with replay, atomic persistence, and fencing. Defines safe compaction and stale-client behavior, weighs OT against CRDT for the stated offline requirements, and adapts ownership and fanout for regional or audience changes without overbuilding v1.