Design Google Docs: the collaborative editing system design walkthrough

Design Google Docs: the collaborative editing system design walkthrough

The request to design Google Docs sounds like one line — many people edit one document together — and that one line hides the whole interview. Picture it for one writer and you reach for a text field and a save button; picture it for a collaborative document editor where a dozen people type into the same paragraph at once, each keystroke appears on everyone's screen in milliseconds, and no one's letter is ever lost, and it becomes one of the hardest problems in distributed systems wearing a friendly interface. This is one of the most revealing collaborative editing system design prompts because it is not about storage or scale first — it is about convergence: concurrent edits that arrive in different orders on different machines must still end as one identical document everywhere.

The round turns on one structural insight. "Everyone edits the same doc" hides the fact that there is no single truth at the instant of typing — each client has its own local copy, edits land in different orders over the network, and the naive fix of last-write-wins throws characters away (two people insert at the same spot, one insertion simply vanishes). The job is not to prevent conflicts but to merge them so they are invisible and every user's intent survives. That merge has exactly two well-known answers — Operational Transformation (OT), where a central server transforms and orders every edit (what Google Docs uses), and CRDTs, where each character carries metadata so edits commute and converge with no coordinator — and naming both, picking one, and justifying it is the spine of the round. Get that reframe — a convergence problem solved by OT or CRDT, coordinated over websockets, persisted as a log of operations — and the rest of the system design interview is deciding how edits are ordered, how your own typing still feels instant, and how a document survives a reload or a dropped connection. This walkthrough follows the path a strong candidate draws on the whiteboard — requirements, estimate, API and data model, high-level design, then the deep dives — naming the follow-up the interviewer uses at each step to tell a memorised answer from real understanding.

How the collaborative editor round is actually run

A collaborative editor round runs about 45 minutes on a shared canvas — you draw the boxes and arrows while you talk, and the interviewer interrupts. It is a favourite because the one-line problem opens onto deep water fast: the moment you draw "everyone edits the same doc," the question becomes what happens when two edits collide and how does every screen agree on the result, and every answer after that compounds from those two. The clock is a touch tighter than the hour-long rounds, so you have to spend your minutes on conflict resolution, sync and persistence, not on the formatting toolbar.

The interviewer rarely lets "everyone sees the changes" stand. "Two people type a character at the exact same position in the exact same instant, and a third deletes that whole line — a second later, what does every screen show, and how do you guarantee it's the same for all of them and nobody's keystroke was lost?" That question — convergence under concurrent edits — is the one a copied answer can never rehearse, and the one this round is really testing.

The rounds here are modelled on how the loop runs, not scraped from any candidate's recall. What matters for prep is the shape: a blank canvas, a tighter clock, and a follow-up after every decision you make.

The five-step framework for any HLD round

Every high-level design answer fits the same spine. Say it out loud at the start so the interviewer knows you have a plan, then walk it:

1. Clarify requirements — functional and non-functional, and what you are explicitly not building.
2. Estimate — editors per document and edit operations per second versus total documents, to justify every later choice.
3. High-level design — the boxes and arrows: the clients, the per-document collaboration server, the sync channel, and the storage.
4. Deep dive — the two or three decisions that actually decide this system.
5. Follow-ups — bottlenecks, failure modes, and what you would change at ten times the scale.

What the debrief measures

The score is not "right or wrong design." A good HLD debrief reads on four dimensions, and every move below maps to one: problem solving (did you reframe it as convergence and reach OT, naming CRDT as the alternative), communication (did you say why last-write-wins loses characters and when you'd pick OT over CRDT, in a single sentence), technical execution (a per-document server assigning a total order over websockets, transforming or merging ops, backed by an append-only op log and snapshots), and time management (did you spend your 45 minutes on conflict resolution, sync and persistence, not on rich-text formatting). Reading a walkthrough teaches the design; it does not teach you to deliver it on the clock while someone pushes back.

Step 1 — Requirements: what a collaborative document editor must do

Spend the first few minutes here. Jumping to boxes before you have scoped the problem is the fastest way to design the wrong system.

Type	Requirement
Functional	Multiple users edit the same document at the same time and see each other's changes live; everyone sees live cursors and presence; users can comment; documents are shared with permissions; revision history is kept.
Functional (optional)	Rich media and embeds, suggestion / track-changes mode, full offline editing, export — call these out, then scope most of them for later.
Non-functional	Convergence — every client ends with an identical document no matter the order edits arrive; edits appear with low latency; nothing is ever silently lost; durable storage and revision history; high availability; scale to many documents, each with up to dozens of simultaneous editors.

The sentence that earns points: "This is a convergence problem, not CRUD — concurrent edits must merge so every screen is identical and no keystroke is lost, and the two ways to do that are Operational Transformation with a central server or CRDTs that commute." Say that and you have framed the entire design before drawing a box.

Step 2 — Capacity estimation (back of the envelope)

Estimation here is about proving one thing: the load is not raw request volume — it is a stream of tiny edit operations that must be ordered per document, plus a lot of ephemeral presence noise.

Quantity	Assumption	Result
Editors per document	usually a handful, occasionally dozens on a hot doc	a small, bounded fan-out per document — the unit of work is one document, not the whole fleet
Edit operations	each keystroke is an op; bursts of many ops/sec per active doc	a high-rate stream of small ops that must be ordered and merged per document
Total documents	millions of documents, most idle at any moment	shard by document id — each doc's collaboration is independent, so the system scales horizontally
Presence updates	cursor moves and selections, very frequent	high-volume but ephemeral and lossy-tolerant — never persisted

Two conclusions fall out, and you should say both out loud. First, the document is the shard — all the hard coordination happens within one document among a few editors, so you can route every editor of a doc to the same collaboration server and keep different docs completely independent. Second, there are two regimes on the wire: the document content (ops, ordering, convergence) must be correct and durable, while presence (cursors) is throwaway — losing a cursor update for a frame is invisible, losing an edit is not. You have now pointed the interview at the real deep dives — conflict resolution, sync and ordering, and persistence — before anyone asked.

Step 3 — API and data model

The API is deliberately small: a client opens a document, streams its operations, and watches everyone else's.

Operation	Shape
open_document(doc_id)	loads the document (snapshot plus the ops after it) and opens a websocket for live sync.
send_operation(doc_id, op, base_version)	submits one edit op (insert/delete at a position) against the version the client last saw.
subscribe_presence(doc_id)	streams live cursors and selections from other editors.
get_document(doc_id)	one-off read of the current content.

The data model is thin. The append-only operation log is the source of truth; snapshots are an optimisation, and presence is never stored:

Entity	Notes
document	doc_id, owner, latest snapshot, current_version, permissions — metadata and the materialised content.
operation	(doc_id, version, author, type, position, char) — the append-only log of every applied edit; the authoritative history.
snapshot	the document content at a given version, written periodically so opening does not replay from zero.
presence	(doc_id, user, cursor, selection) — ephemeral, held in memory on the collaboration server, never persisted.

Step 4 — High-level design: the collaboration server, sync and storage

Now the boxes. The clients connect over websockets to a per-document hub, backed by durable storage:

• Websocket gateway: holds the long-lived connections and routes every editor of a document to the same collaboration server.
• Collaboration server (per document): the heart of the system. It receives each operation, assigns it a monotonically increasing version (a total order for that document), transforms it against concurrent ops (OT) or merges it (CRDT), and broadcasts the result to every other editor. It holds the live presence for the doc in memory.
• Operation log: every applied op is appended to a durable append-only log — the source of truth and the basis for revision history.
• Snapshot store: the document content is snapshotted periodically so opening a doc loads a recent snapshot and replays only the tail.
• Document / sharing service: owns metadata, permissions, sharing and revision history, layered on the same log.
• Sharding: everything shards by document id — a hot document is one collaboration server's load, and the system scales by spreading documents across servers.

Say explicitly that the document is the unit of coordination: route all its editors to one server that assigns a single total order, and keep content durable while presence stays ephemeral. Naming that — a per-document hub that orders and fans out ops over websockets, backed by an op log — is a signal the interviewer is listening for.

Deep dive: concurrent editing and conflict resolution (OT vs CRDT)

This is the decision the whole round is really about. The follow-up is the collision: two people insert a character at the same position at the same instant — what does each approach do so nobody's keystroke is lost?

Start by killing the naive answer out loud: last-write-wins loses data. If two edits target the same position and you simply keep the later one, you have silently deleted a real keystroke — unacceptable for an editor. Both correct answers instead treat edits as operations and make them merge so every intent survives. Name both, then pick one:

	Operational Transformation (OT)	CRDT (conflict-free replicated data type)
Idea	transform each incoming op against the concurrent ops already applied, so its position is corrected	give every character a unique, ordered position id so ops commute and merge in any order
Coordination	needs a central server to transform and assign a total order	no coordinator required — any replica converges on its own
Where complexity lives	transformation logic + ordering on the server	data structure + per-character metadata on the replicas
Best topology	classic client-server (what Google Docs uses)	offline-first / peer-to-peer (Figma moved OT → CRDT)
Cost	tricky transform functions, but compact ops	simple merge, but metadata overhead per character

For a Google Docs-style, server-centric design, pick OT: a central collaboration server already exists to fan out edits, so let it transform each op against the ones it has ordered and assign the version — two inserts at the same position are transformed so the second shifts past the first, and both survive. Then say the one sentence that shows range: both OT and CRDT solve the same failure mode — concurrent edits meaning different things depending on order — but OT centralises the coordination while CRDTs push it into the data, so I'd reach for a CRDT if the requirement were offline-first or peer-to-peer. That is the trade-off the round is testing.

"Two people insert a character at the same position at the same time — what happens so nobody's keystroke is lost?" Never last-write-wins — that deletes a real edit. With OT, the central server transforms the second op's position against the first it already ordered, so one shifts past the other and both characters survive in a single agreed order. With a CRDT, each character carries a unique ordered position id so the two inserts commute and every replica merges to the same result without a server. Both converge; neither drops a keystroke.

System Design
HLD · Messaging & realtime · 45 min
Design Google Docs out loud, with follow-ups

Practise on Zynter →

Deep dive: real-time sync, ordering and presence

Conflict resolution decides how edits merge; this decides how they travel and why your own typing still feels instant. The follow-up is about agreement: how does every client end up applying edits in the same order, and why doesn't my cursor lag while I type?

The answer is a total order per document owned by the collaboration server, with an optimistic local copy on each client:

• Local-first feedback: when you type, your client applies the op to its local copy immediately, so your own typing is instant — it never waits for the server round-trip.
• Server assigns the order: the op is sent over the websocket to the collaboration server, which assigns it the next version number — this monotonic sequence is the single total order every client will agree on.
• Transform and broadcast: the server transforms (OT) or merges (CRDT) the op against what it has already ordered, then broadcasts the result to every other editor, who applies it to their local copy.
• Reconcile your own copy: because you applied optimistically, your client reconciles when the server's acknowledged order comes back — if someone else's op was ordered first, your local state is adjusted to match the agreed sequence. Everyone converges on the server's order.
• Presence on the side: cursors and selections ride the same websocket but are ephemeral — broadcast best-effort, never ordered or stored, because a dropped cursor frame is invisible while a dropped edit is not.

The point to state plainly: there is one authority on order per document — the collaboration server's version sequence — and clients are allowed to run ahead locally for responsiveness only because they always reconcile back to that order. Instant typing is a UI trick over a strictly ordered, converging log; the order itself is never democratic.

"How does every client agree on the order of edits, and why does my own typing feel instant?" My client applies each keystroke to its local copy immediately for instant feedback, then sends the op to the per-document collaboration server, which assigns it a version — the one total order everyone agrees on — transforms it, and broadcasts it. Each client reconciles its optimistic local state back to that order. Presence rides the same channel but is best-effort, because losing a cursor frame is harmless and losing an edit is not.

System Design
HLD · Messaging & realtime · 45 min
Defend the total-order sync model out loud

Practise on Zynter →

Deep dive: persistence, storage and reconnection

Merging and ordering keep a live session consistent; this decides what happens when a doc is reopened a week later or a laptop drops off wifi mid-sentence. The follow-up is the disconnect: my connection drops for thirty seconds while I keep typing — what happens to my edits and how do I catch up?

The durable truth is not the current text — it is the sequence of operations that produced it. Store the document as an append-only operation log, with periodic snapshots so you never replay from the beginning:

• Op log is the source of truth: every applied op is appended with its version; the whole document history — and revision history — is reconstructable from it.
• Snapshots to bound replay: periodically write the full content at a version; opening a document loads the latest snapshot and replays only the ops after it, so load time stays bounded no matter how old the doc is.
• Version-driven catch-up: every client tracks the last version it saw. On reconnect it tells the server "I last saw version N," and the server sends only ops N+1 onward — a cheap delta, not the whole document.
• Offline buffering: edits made while disconnected are buffered locally against the client's last-known version; on reconnect they are sent, transformed against anything that happened meanwhile, and merged — the same conflict-resolution machinery, just delayed.
• Shard and layer: the log is sharded by document id, and comments, sharing/permissions and revision history all layer on top of the same ordered log.

The point to state plainly: because the document is a log of ordered operations, reconnection and offline are not special cases — they are just a client that fell behind and needs the ops it missed, reconciled through the same transform step. Snapshots make opening fast; version numbers make catching up cheap; the op log makes nothing ever truly lost.

"My connection drops for thirty seconds while I keep typing — what happens to my edits and how do I catch up?" Your edits are buffered locally against the last version you saw, and your screen keeps updating optimistically. On reconnect, your client says 'I last saw version N,' the server streams the ops you missed from N+1 on, and your buffered edits are transformed against them and merged into the agreed order. The op log plus snapshots mean the doc reloads fast and no edit is lost — a disconnect is just a client that fell behind.

The follow-ups that decide the collaborative editor round

Scan the probes from each deep dive and they rhyme. Master these five and you are ready for a version of the question that is not drawn exactly like this one.

• "Why not just use last-write-wins for conflicting edits?" → Because it silently deletes real keystrokes: two inserts at the same position would leave only one. You treat edits as operations and merge them with OT or a CRDT so every intent survives and all clients converge. (problem solving)
• "OT or CRDT — which and why?" → OT for a classic client-server design like Google Docs, where a central server already fans out edits and can transform and order them; a CRDT if the requirement were offline-first or peer-to-peer, since its ops commute and converge without a coordinator at the cost of per-character metadata. (communication)
• "How does every client agree on the order of edits?" → The per-document collaboration server assigns a monotonically increasing version to each op — one total order — transforms it, and broadcasts it; clients apply optimistically for instant feedback and reconcile back to that order. (technical execution)
• "My wifi drops mid-sentence — what happens?" → Edits are buffered locally against the last version seen; on reconnect the client requests ops from that version onward, the server streams the delta, and the buffered edits are transformed against them and merged — a disconnect is just a client that fell behind. (technical execution)
• "How do you store the document and keep revision history?" → As an append-only operation log with periodic snapshots; opening loads a snapshot and replays the tail, revision history is reconstructable from the log, and everything shards by document id. (problem solving)

Each maps to a debrief dimension. Reading this list teaches you the answers; it does not teach you to deliver them while someone interrupts — that only comes from saying them out loud.

How to prepare: a one-week plan

You do not need fifty systems. You need this one cold and the framework automatic, so the next "design X" is just new nouns in the same five steps.

• Days 1–2: Learn the five-step framework until it is reflex. Do the collaborative editor end to end on paper — requirements, estimate, API, data model, and the collaboration-server/sync/storage boxes.
• Days 3–4: Drill conflict resolution: why last-write-wins loses characters, how OT transforms and orders ops on a central server, and how a CRDT commutes with position ids — and when you'd pick each. Say each tradeoff in one sentence.
• Days 5–6: Own sync and persistence — the per-document total order and optimistic local copy, presence as ephemeral, and the op log plus snapshots with version-driven reconnection. Answer each of the five follow-ups out loud.
• Day 7: A full timed 45-minute round, narrating the whole way, with someone (or something) interrupting. This is the rep that counts.

This post is the deep walkthrough behind one row of the broader Top 25 system design interview questions — once the collaborative editor is automatic, the same spine carries the rest of the list.

Frequently asked questions

How do I design Google Docs step by step?

Follow the five-step HLD framework. Clarify requirements (multiple users edit one rich-text document at once and see changes live, with cursors, comments, sharing and revision history, and the hard rule that every client converges to an identical document and no edit is lost); estimate to show that the unit of work is one document with a few editors and a stream of tiny ops, sharded by document id; define the small API (open_document, send_operation against a base version, subscribe_presence, get_document) with an op-log/snapshot/presence model; draw the design (clients over websockets to a per-document collaboration server that assigns a total order, transforms or merges ops and broadcasts them, backed by an append-only op log and snapshots); then deep-dive conflict resolution (OT vs CRDT), sync and ordering, and persistence with reconnection. Finish on the follow-ups about collisions and dropped connections.

How does a collaborative editor handle concurrent edits without losing data?

By treating every edit as an operation and merging operations rather than overwriting. Last-write-wins is wrong because two edits at the same position would leave only one, silently deleting a keystroke. The two correct approaches are Operational Transformation, where a central server transforms each incoming op against the concurrent ops it has already ordered so positions stay correct, and CRDTs, where each character carries a unique ordered identifier so operations commute and every replica merges to the same result. Both guarantee convergence — every client ends with an identical document — and both preserve every user's intent, so no keystroke is ever thrown away.

What is Operational Transformation (OT)?

Operational Transformation is the conflict-resolution technique Google Docs uses. Edits are expressed as small operations — insert a character at a position, delete at a position — and a central collaboration server transforms each incoming operation against the operations it has already applied, adjusting its position so it still means what the author intended, then assigns it a place in a single total order and broadcasts it to everyone. For example, if one user inserts at position 2 and another concurrently inserts at position 2, the server transforms the second so it lands after the first, and both characters survive. The complexity lives in the transform functions and the server's ordering, which is why OT fits a classic client-server topology.

OT vs CRDT — what's the trade-off?

They solve the same failure mode — concurrent edits meaning different things depending on the order they arrive — but they put the complexity in different places. OT centralises coordination: a server transforms and orders operations, which keeps per-operation data small but requires a central authority and careful transform logic, and it is what Google Docs uses. CRDTs push the intelligence into the data: each element carries metadata (a unique ordered position id) so operations commute and any replica converges with no coordinator, which enables offline-first and peer-to-peer collaboration at the cost of extra metadata per character — the direction Figma took. Pick OT for a server-centric design and a CRDT when you need offline or P2P.

How is a collaborative document stored, and what happens on reconnect?

The document is stored as an append-only log of operations, with periodic snapshots of the full content. Opening a document loads the latest snapshot and replays only the operations after it, so load time stays bounded regardless of the document's age, and revision history is reconstructable from the log. Each client tracks the last version it applied; on reconnect it tells the server the last version it saw and receives only the operations after that — a cheap delta — while any edits it made while offline are buffered locally and then transformed against what it missed and merged. Because the document is an ordered log, a dropped connection is just a client that fell behind and needs to catch up, not a special case.

How do I practise a system design interview out loud?

Reading a walkthrough is not the same as defending a design while someone interrupts. On Zynter, the HLD track runs live voice rounds modelled on how real system design loops run — you talk through a shared design on the canvas, and a voice interviewer pushes with the follow-ups above one at a time, then gives you a debrief on problem solving, communication, technical execution, and time management. The score is a practice signal, not a hiring decision.

Practise it on Zynter

You can read what OT and CRDT mean. The round is won on reaching convergence out loud.

Pick the Collaborative Document Editor round, draw the collaboration-server, sync and storage design on the canvas, and defend it out loud to a voice interviewer that keeps asking "two people type at the same spot — whose keystroke wins?" and "my wifi drops mid-sentence — what happens?" — then read the debrief. Zynter.ai is on-demand mock interviews modelled on real company loops, with 150+ rounds across 20 companies including the HLD system design track (Sep 2026).

Practise the Collaborative Editor round →
Browse all interview tracks