Loading…

Design a Collaborative Document Editor (Google Docs) - SystemRound

Design a Collaborative Document Editor (Google Docs)

hardSystem design45 min5 stagesPro

Asked atGoogleMicrosoftAtlassianNotionFigmaDropbox

Design the editing backbone of a Google Docs–style product: many people open the same document and type at the same time. Each editor sees their own keystrokes instantly and everyone else’s within a fraction of a second, with live cursors and presence. The defining challenge is convergence — concurrent edits must never be silently lost, and every client must end up with an identical document. That forces a real conflict-resolution model (OT or CRDT), a server-assigned total order per document, and an append-only operation log with periodic snapshots, rather than last-write-wins on a document blob.

Best after a few full reps. Expect follow-up questions, edge cases, and deeper trade-off discussion.

What this problem tests

Document & Op APIsSync & AcknowledgementAuth & Presence ChannelCore ComponentsConflict Resolution & Total Order (the twist)Edit Flow

Round shape

5 stages

Time budget

45 min

Feedback loop

Grade anytime

Guided practice·Primary loop

Guided practice

Workspace-first, hints visible, stage retry available. The cheap, repeatable loop — build the answer shape before you take it under pressure.

Stage-by-stage workspace instead of a blank page.
Grade one stage or the whole answer whenever you want.
Compare your reasoning against reference criteria and model answers.

Solve once, compare against the checklist, then come back to the weak stage instead of starting over.

Mock interview·Pressure test

Mock interview

Strict timer, hints hidden, debrief deferred to the end. Use this once you can already structure a clean answer and want to pressure-test pacing and pushback.

Best once the answer shape is already in your head.
Pressure-test pacing, pushback handling, and communication.
Use diagnosis after the interview for exact misses and next study steps.

Best after one structured rep · timed · focused on pacing and communication.

Requirements

This is the framing pass. A strong answer quickly defines what the system must do, what quality bar it has to hit, and the numbers that will justify the rest of the design.

First 5 min of the round

What must exist

Functional Requirements

5 items

1Many users edit the same document concurrently in real time.

2Every edit propagates to all collaborators and all clients converge to an identical document.

3No concurrent edit is silently lost — if two people insert at the same spot, both survive.

4Every edit is durably persisted; reopening restores the document exactly.

5Live cursors / presence — in scope but ephemeral (no durability guarantee).

What good looks like

Non-Functional Requirements

3 items

1Local echo p99 < 50ms (your own keystroke), remote propagation p99 < 200ms (others see it).

2Convergence: strong per-document operation ordering so all clients match.

399.9% availability on the edit path; durability — an acknowledged edit is never lost.

Numbers to anchor the design

Scale Estimation

3 items

150M DAU, 100M docs; ~2M docs actively co-edited at peak; ~5M concurrent WebSocket connections.

2Op throughput: active editors × a few keystrokes/sec ≈ ~300K ops/sec at peak.

3A hot doc with ~100 editors fans one op out to ~100 receivers — fan-out, not raw op rate, is the pressure.

How the round unfolds

Each stage has a distinct job. Treat them like separate deliverables instead of one giant answer, and the round becomes much easier to navigate.

4 design stages · 40 pts after framing

🔌

Stage 2~5 min10 pts

API Design

Define the contract clearly: the endpoints, auth boundary, error semantics, and the one or two decisions that matter most.

What you should produce

Now define the API. How does a client open a document, and how does it exchange edits in real time? Be explicit about the realtime channel, the ope...

Strong answers cover

Document & Op APIsSync & AcknowledgementAuth & Presence Channel

🏗️

Stage 3~10 min10 pts

High-Level Architecture

Lay out the main components and trace the write path, read path, and any async path cleanly.

What you should walk through

Walk me through the architecture.

Strong answers cover

Core ComponentsConflict Resolution & Total Order (the twist)Edit Flow

💾

Stage 4~10 min10 pts

Data Model & Storage

Pick the store, show the schema or key model, and explain why that storage choice fits the access pattern.

What you should lock in

Let's get concrete about storage.

Strong answers cover

Op Log as Source of TruthSnapshots & CompactionStore Choice & Durability

📈

Stage 5~15 min10 pts

Scaling & Deep Dive

Name the first bottleneck, failure modes, and the trade-offs that keep the system fast and reliable under pressure.

What you should pressure-test

Let's deep dive. Where does this design bottleneck first as it scales, and how do you handle a hot document, session-server failure, reconnection,...

Strong answers cover

Bottleneck IdentificationFailover & ReconnectFan-out & Ops

What a strong first rep looks like

Scope clearly

Translate the prompt into concrete requirements, scale, and trade-offs before drawing architecture.

Stay stage-specific

Give APIs in the API stage, data models in the storage stage, and failure modes in scaling. Don't blur them together.

Iterate fast

Grade early, compare to the reference reasoning criteria, fix the biggest misses, and re-submit the weak stage instead of starting over.