Design a collaborative document editor like Google Docs

Requirements: scoping a shared document

"Build Google Docs" hides at least five products: a rich text editor, a sync engine, a presence system, a comment system, and a version history. Each one could fill an interview on its own. Your first job is to find out which of them the interviewer cares about, and how big and how live the problem is. Spend the first five minutes on questions whose answers move the design.

The questions below are in the order a senior engineer would ask them: first how many people edit at once and how big documents get, because those numbers pick the merging approach. Then what "live" means, what happens offline, and what a document can contain. The table shows the answer this guide assumes and which part of the design changes if the answer is different.

Functional requirements

• Open a document and start reading within about 2 s, even if it has 300 pages.
• Type and format text (headings, lists, bold, links, images, tables), with every keystroke showing instantly.
• See other people's edits appear live, and see who is in the document and where their cursors are.
• Select a range of text and leave a comment on it. The comment stays attached to that text while others edit around it.
• Undo and redo your own changes, without undoing anyone else's.
• Browse earlier versions, see who changed what, and restore an old version.
• Keep editing without a connection, and have the changes merge when the connection returns.

Non-functional requirements, with numbers

Non-functional requirements are qualities, not features. Each one needs a number, because "fast" and "reliable" can't be tested and a number can. For an editor, the most important number is input latency: the time from a key press to the letter on screen. Typing is the one thing users do thousands of times per session, and any lag there feels broken.

• Local echo in one frame. A typed character appears within 16 ms, the length of one frame at 60 frames per second. Heavier actions, like pasting 10 pages, stay under 200 ms (INP, Interaction to Next Paint).
• Remote edits within 300 ms. When two people are online, each sees the other's change within about 300 ms at the 75th percentile, and within 1 s at the 99th.
• Convergence. When everyone stops typing and all messages arrive, every copy of the document is exactly the same. No exceptions.
• No lost keystrokes. Once a change shows as saved, it survives a crash. Changes not yet saved survive a closed tab or a dead battery, because they're also stored on the device.
• Scale per document. 100 people editing, each typing up to 8 characters per second. That's up to 800 keystrokes per second for the server to order on one document.
• Big documents stay smooth. Scrolling a 300-page document stays near 60 frames per second, and typing on page 250 is as fast as typing on page 1.
• Accessible. Screen readers can read and edit the document, every command has a keyboard shortcut, and live changes from others never interrupt the reader.

Out of scope, said out loud

• Suggestion mode (tracked changes). It's a layer on top of the same operations: a suggestion is an edit stored with an "unapproved" flag. Mention it, don't design it.
• Spreadsheets and slides. They share the sync engine but have their own models.
• Printing, PDF export, and pixel-perfect page layout. We break the document into pages, but we don't match a print engine.
• The storage cluster behind the server. We describe what the server must guarantee (one order of changes per document), not how it replicates its disks.

What makes collaborative editing hard

A single-user editor is already a hard component: selections, IME input for languages like Japanese, paste, and layout. Collaboration adds problems of a different kind. They come from one fact: every person has their own copy of the document, and the copies change at the same time. Name these traits before you design, because each one turns into a decision later.

• Nobody waits for the network. A keystroke must show in 16 ms, but a round trip to the server takes 50 to 300 ms. So each browser edits its own copy first and tells the others later. For a short time, the copies disagree.
• Positions move. An edit says where it happens, such as "insert at character 120". If someone else just typed 5 characters earlier in the text, character 120 is now somewhere else. Every position (edits, cursors, comment ranges, undo steps) goes stale the moment someone else types.
• Intent, not just equal copies. It's easy to make every copy equal: throw away all but one person's work. The real goal is to keep what each person meant. If Alice bolds a word while Bob fixes a typo in it, the result should be a bold, corrected word.
• Rich structure. A document is not one long string. It has paragraphs, list items, tables, images, links, and comments. Each kind of change (split a paragraph, add a table row, bold a range) must merge with every other kind.
• Long lives. Documents live for years and sessions last hours. History grows forever, and a person can come back from a week offline with 500 changes made on an old copy.
• Big and busy. A 300-page document with 100 people in it must still type and scroll smoothly on an ordinary laptop.

The figure shows the core problem in its smallest form. Two people start with the same text and each makes one edit at the same moment. If each browser simply applies the other person's edit as it arrives, the copies end up different, and they stay different forever. Every system in this guide is an answer to that picture.

What to send: the whole document or the change

Before deciding how to merge, decide what travels over the network. The naive answer is the one most apps use for forms: when something changes, save the whole thing. A 300-page document is about 1 MB of text and formatting, so saving it every 2 seconds while someone types is 0.5 MB per second of upload for one person. With 20 people typing, the server receives 10 MB per second for a single document, and almost all of it is text that didn't change.

Size is the smaller problem. The bigger one is that a whole document says nothing about what changed. If Alice's save and Bob's save arrive one after the other, the server only sees two different documents. It can keep one and lose the other, or compare them, which is the second option below.

What an operation looks like

Most editors describe a change as a walk through the document from the start: keep (retain) some characters, insert some, delete some, keep the rest. Quill's Delta format and many OT libraries work this way. The walk form is handy because it describes the whole document in one pass, and it composes: two walks in a row can be folded into one. For explaining merges, the simpler form with a position is enough, so this guide uses both, as below.

// Position form: easy to read and explain.
type Op =
  | { type: "insert"; pos: number; text: string; attrs?: Marks }
  | { type: "delete"; pos: number; length: number }
  | { type: "format"; pos: number; length: number; attrs: Marks };

type Marks = { bold?: boolean; italic?: boolean; link?: string | null };

// Walk form (like Quill Delta): retain, insert, delete in order.
type Step = { retain: number; attrs?: Marks } | { insert: string; attrs?: Marks } | { delete: number };

const boldThenBang: Step[] = [
  { retain: 10 },
  { retain: 5, attrs: { bold: true } }, // bold characters 10 to 15
  { insert: "!" },                      // then type "!" at 15
];

Structure needs ops too. Pressing Enter in the middle of a paragraph is a split at a position. Backspace at the start of a paragraph is a merge with the previous one. Changing a paragraph into a heading sets a block attribute.

Every new op type you add must merge correctly with every other one, so the list of op types is a cost. Keep it short: insert, delete, format text, and set block attributes cover most of a document.

Concurrency: who wins when two people type at once

Now take a concrete case. Alice and Bob both open revision 40 of a design doc. Alice fixes a typo in paragraph 2. At the same moment, Bob adds a sentence to paragraph 9.

Neither edit touches the other's text. A good design keeps both without anyone noticing. There are four families of answers, and the first three are what most web apps already use for other data.

Each one is worth naming in the interview, because each is right for some data. Sharing settings, the document title, and comment text are all edited by one person at a time, and simple rules work for them. The body text is where the simple rules break.

Merging keeps work, not always meaning

Real-time merging promises that nobody's keystrokes vanish. It can't promise that the result reads well.

Say the text is teh and both Alice and Bob fix it to the at the same moment, each by deleting eh and typing he. Both deletes remove the same characters, so one of them becomes a no-op. Both inserts survive, because each is someone's typing. The merged text is thehe.

That's the right outcome. The system can't know the two people meant the same fix, and keeping both is better than silently dropping one. A human sees thehe and fixes it in one second, and live cursors make it obvious why it happened.

In the interview, say this out loud: merging guarantees convergence and keeps everyone's input, and people fix the rare semantic clash. That framing shows you understand the limits of the algorithms, not just their names.

Operational transformation: rewriting late operations

Operational transformation (OT) keeps ops as plain "insert at position" and "delete at position" instructions, and fixes the positions when ops cross. The fix is a function, usually called transform. It takes an op a and another op b that was applied first, and returns a': the same intent, rewritten so it applies correctly after b.

The one rule transform must follow is called TP1 (transformation property 1). Start from the same document. Path one applies a, then b', and path two applies b, then a'. Both paths must give the same document.

If that holds for every pair of op types, two people who apply each other's ops in either order end up with the same text. The diamond in the figure is the picture to draw on the whiteboard.

Four worked examples

In each one, Alice and Bob start from the same text at server revision 10, and Alice's op reaches the server first. Count positions from 0: in buy milk, the space is at 3 and m is at 4. Work each one by hand before reading the answer, then step through them in the lab below.

1. Inserts in different places. Text buy milk. Alice inserts oat at 4. Bob inserts ! at 8. Alice's 4 characters land before Bob's spot, so Bob's op becomes insert ! at 12. Alice's op lands before Bob's, so it doesn't change. Both get buy oat milk!.
2. Inserts at the same spot. Alice inserts 2 at 4 and Bob inserts oat at 4. Neither position is "before" the other, so a tie rule decides, and both sides must apply the same rule. The code below keeps the op with the lower client id on the left, and Alice's id is lower. Bob's op becomes insert at 6. Both get buy 2 oat milk.
3. Insert after a delete. Text buy oat milk. Alice deletes buy (4 characters at 0). Bob types s at 7, to make oats. The 4 characters before Bob's spot are gone, so his op becomes insert at 3. Alice's delete is before Bob's insert, so it doesn't change. Both get oats milk.
4. Overlapping deletes. Text buy oat milk. Alice deletes oat (4 at 4). Bob deletes buy oat (8 at 0). Bob's op loses the 4 characters Alice already removed and becomes delete 4 at 0. Alice's op is entirely inside Bob's, so on Bob's side it becomes nothing. Both get milk.

One more case matters for intent. If Bob types inside a range that Alice deletes, the transformed delete must split into two deletes around his text. Otherwise Alice's delete would erase letters she never saw. That is how OT preserves intention: each person's op only ever affects the characters that person could see.

type TextOp =
  | { type: "insert"; pos: number; text: string; client: string }
  | { type: "delete"; pos: number; length: number; client: string };

// Rewrite `op` so it applies to the document after `other` was applied.
function transform(op: TextOp, other: TextOp): TextOp[] {
  if (other.type === "insert") {
    const n = other.text.length;
    if (op.type === "insert") {
      const staysLeft = op.pos < other.pos || (op.pos === other.pos && op.client < other.client);
      return [staysLeft ? op : { ...op, pos: op.pos + n }];
    }
    if (other.pos <= op.pos) return [{ ...op, pos: op.pos + n }];
    if (other.pos >= op.pos + op.length) return [op];
    // `other` typed inside the range: delete around it, never over it.
    return [
      { ...op, pos: other.pos + n, length: op.pos + op.length - other.pos },
      { ...op, length: other.pos - op.pos },
    ];
  }
  const shift = (p: number) => (p <= other.pos ? p : Math.max(other.pos, p - other.length));
  if (op.type === "insert") return [{ ...op, pos: shift(op.pos) }];
  const end = Math.min(op.pos + op.length, other.pos + other.length);
  const overlap = Math.max(0, end - Math.max(op.pos, other.pos));
  const length = op.length - overlap;
  return length > 0 ? [{ ...op, pos: shift(op.pos), length }] : [];
}

Why OT wants a central server

With a server in the middle, every op gets a number in one global order: revision 11, 12, 13, and so on. A client sends its op with the revision it was based on, say baseRev: 10. If the server is at 13, it transforms the op past revisions 11, 12, and 13, saves it as 14, and sends it to everyone. Every transform happens along that one agreed order, so TP1 is all the system needs.

Without a server, peers receive ops in different orders, and transforms must also satisfy a second, much harder property (TP2): transforming an op past two concurrent ops must give the same op whichever order those two are taken in. Several published peer-to-peer OT algorithms were later shown to break it.

This is the main reason production OT systems, including Google Docs and the older Google Wave, put one server in charge of ordering each document. The design goes back to the Jupiter system from Xerox PARC in 1995: each client only ever syncs with the server, never with other clients.

CRDTs: giving every character an identity

OT fixes positions after the fact. A CRDT (conflict-free replicated data type) removes the need for positions in the first place.

In a sequence CRDT, every character gets a permanent, unique id when it's typed, usually the pair (client id, counter): Alice's 7th character is A7. An insert doesn't say "at position 12". It says "after the character with id A3". Ids never change, no matter what anyone else does, so there's nothing to transform.

The rules are designed so that applying the same set of ops in any order gives the same result. That's the property that lets CRDTs work without a central server: peers can sync directly, or after a week offline, in any order, and still converge. Libraries such as Yjs and Automerge package this up for JavaScript.

Two inserts after the same character

If Alice and Bob both insert right after A3, both new characters claim the same left neighbor. A fixed rule orders them, for example by comparing their ids, and every client applies the same rule, so all copies agree. RGA (Replicated Growable Array) places the newer insert first. YATA, the algorithm inside Yjs, also records the right neighbor at insert time.

These details matter for intent. Both RGA and YATA keep a word typed left to right in one piece, because each letter is inserted after the one before it. Some simpler designs, such as Logoot, give each character a fractional position instead. There, two people typing oat and soy at the same spot can end up with their letters interleaved, like osoayt, which is converged but useless.

Tombstones: why deleted characters stay

When Alice deletes a character, Bob may at that very moment be inserting "after" it. If the character vanished from Alice's copy, Bob's op would arrive pointing at an id that no longer exists.

So deletes don't remove the character. They mark it as deleted and hide it. That hidden record is a tombstone. It stays as long as any client might still send an op that refers to it, which, with offline clients, can be forever.

What identities cost in memory

A naive sequence CRDT stores one object per character, with an id, a left neighbor id, a deleted flag, and the character. In JavaScript that's easily 50 to 100 bytes per character instead of 1 or 2. A 1 million character document would need 50 to 100 MB before counting tombstones, and a document that has seen years of rewriting may have more deleted characters than live ones.

Real libraries are far more compact. Text typed in one go by one person has consecutive ids (A8, A9, A10...), so Yjs stores the whole run as one item, and splits it only when someone edits in the middle. Deleted runs keep their structure but drop their content. Automerge stores its history in a compressed column format.

With these tricks, the overhead for normal documents is small. It still grows with editing history, and removing tombstones completely requires knowing that every copy has seen the delete, which is hard when some copies are offline.

The document model and rendering

Ops need something to apply to. The browser offers an obvious candidate: put contenteditable on a div, and the browser gives you a caret, selection, typing, IME input for languages like Chinese and Japanese, spell check, and screen reader support for free. The naive design treats that DOM as the document: let the browser edit it, and read the HTML back to save it.

That breaks quickly. Browsers produce different HTML for the same action: pressing Enter may create a div, a p, or a br depending on the browser and the context. Pasting from a word processor brings in hundreds of nested span tags with inline styles. The browser's own undo stack knows nothing about remote edits.

Worst of all, the DOM tells you what it looks like now, not what the user did: a MutationObserver reports changed nodes, not "Bob typed e at 41", so you're back to guessing with diffs. And when a remote op changes the DOM directly, the browser's caret and the IME composition in progress can jump or break.

The shape of the model

The model is a tree: a document holds blocks (paragraphs, headings, list items, images, tables). Text blocks hold runs: stretches of text with the same marks, like bold or a link. Every block has a stable id, which helps rendering (only the changed block re-renders) and comments. Ops still address the document with one flat integer position, counting each character and one step for each block boundary, so transform stays simple arithmetic.

type Marks = { bold?: true; italic?: true; link?: string; comment?: string[] };

type Run = { text: string; marks: Marks };

type Block =
  | { id: string; type: "paragraph"; runs: Run[] }
  | { id: string; type: "heading"; level: 1 | 2 | 3; runs: Run[] }
  | { id: string; type: "listItem"; ordered: boolean; depth: number; runs: Run[] }
  | { id: string; type: "image"; src: string; width: number; height: number; alt: string }
  | { id: string; type: "table"; rows: { cells: { blocks: Block[] }[] }[] };

type DocModel = {
  id: string;
  rev: number;        // last server revision folded into this copy
  blocks: Block[];
};

From key press to pixels

1. The user presses e. The browser fires beforeinput with inputType: "insertText" and data: "e".
2. The editor calls preventDefault(), reads the selection from the model (not the DOM), and builds the op: insert e at 41.
3. The op is applied to the model, recorded for undo, and handed to the sync client. None of these wait for the network.
4. The renderer updates only the changed block's DOM and puts the selection back where the model says it is. Total time: a few milliseconds.
5. IME input is the exception. During composition (compositionstart to compositionend), insertCompositionText events can't be cancelled, so the editor lets the browser change the DOM, then reads the final text and turns it into an op when composition ends. Remote ops that arrive meanwhile are held or carefully mapped, so they don't break the composition.

The sync protocol: local first, then the server

We have ops, a model, and OT with a central server. The sync protocol is the set of rules that ties them together. The naive version sends every op the moment it's made and applies every op from the server the moment it arrives. That diverges for the reason we saw in the second chapter: an op from the server was made on a document that didn't include your newest keystrokes, and your keystrokes were made on a document that didn't include it.

The fix is for each client to track exactly which of its ops the server has seen. The design that does this was popularized by Google Wave and the ot.js library, and it keeps every client to a very simple contract: at most one batch of ops in flight to the server at a time.

Three states: synced, in flight, and pending

• Synced. The local document equals server revision rev. Nothing is waiting.
• In flight. The client sent one batch of ops based on rev and is waiting for the server's ack. Its local document is rev plus that batch.
• In flight plus pending. The user kept typing while waiting. New ops are composed into one pending batch, which is not sent until the in-flight one is acked.

Three events move the client between states. A local edit applies to the model at once and joins the pending batch, which is sent right away if nothing is in flight. An ack sets rev to the revision the server gave the batch, clears in flight, and sends pending if there is any.

A remote op from the server was ordered before everything the client hasn't had acked, so the client transforms the remote op past its in-flight batch and then its pending batch, applies the result, and transforms its own two batches past the remote op so they stay correct. The server does the matching transform when the in-flight batch arrives, so both sides land on the same text.

class SyncClient {
  rev = 0;                       // last server revision applied here
  seq = 0;                       // per-client counter, for dedupe
  inflight: Op[] | null = null;  // sent, waiting for an ack
  pending: Op[] = [];            // typed since, not sent yet

  onLocal(ops: Op[]) {
    this.pending = compose(this.pending, ops);
    if (!this.inflight) this.flush();
  }
  onAck(rev: number) {
    this.rev = rev;
    this.inflight = null;
    this.flush();
  }
  onRemote(rev: number, ops: Op[]) {
    let theirs = ops;
    if (this.inflight) [this.inflight, theirs] = transformPair(this.inflight, theirs);
    [this.pending, theirs] = transformPair(this.pending, theirs);
    this.rev = rev;
    this.model.apply(theirs);    // also maps cursors and comment anchors
  }
  private flush() {
    if (this.pending.length === 0) return;
    [this.inflight, this.pending] = [this.pending, []];
    this.socket.send({ type: "op", baseRev: this.rev, seq: ++this.seq, ops: this.inflight });
  }
}

What the server guarantees

The server side is short to describe but carries the correctness. Each document is owned by exactly one server process at a time, chosen by hashing the document id, so ops for one document are handled one after another, never in parallel. For each incoming batch, the server transforms it past every revision after its baseRev, appends it to the log as the next revision, waits for the write to be durable, then acks the sender and broadcasts to everyone else.

Two details prevent rare bugs. First, the server remembers the last seq it applied per client. A client that reconnects resends its in-flight batch, because it never saw the ack. If the server already applied it, it re-sends the ack instead of applying it twice.

Second, the WebSocket runs over TCP, so messages on one connection arrive in order. A client never sees revision 15 before revision 14, and if a gap appears after a reconnect, it asks for the missing range.

Batching and operation granularity

A fast typist makes 8 keystrokes per second. With 100 people on a document, one op per keystroke is up to 800 messages per second into the server, and each one is broadcast to 99 others. Batching cuts that, but a fixed delay adds latency everyone can feel. The question is how to batch.

Composing is what keeps batches small. Insert h at 40 followed by insert e at 41 composes into insert he at 40. Typing a whole sentence during one slow round trip becomes one insert. Deletes compose the same way.

Note that network batching and undo grouping are separate decisions: a batch is about efficiency, while an undo step is about what the user thinks of as one action. Don't let one decide the other.

Presence and remote cursors

Presence is who is in the document right now, and where: their name, color, cursor, and selection. It looks like document data, but it behaves differently. It changes many times a second, it's only useful for a few seconds, and nobody needs it in the history, so it doesn't go through the op log. It travels on the same WebSocket as a separate message type, and the server keeps it only in memory.

A cursor is a position, so it goes stale like an op does. Say Bob's caret is at 5, at the end of a car, and Alice types red at 2, so the text becomes a red car. On Carol's screen, position 5 is now right after red, so Bob's caret jumps to the wrong word unless something moves it to 9. Waiting for Bob's next presence message isn't good enough: Bob might be reading and not moving at all.

Keeping presence traffic in check

Presence is the chattiest part of the system. If 100 people each send 10 cursor updates per second, the server receives 1,000 messages per second, and relaying each to 99 others is 99,000 messages per second for one document. Three rules keep it sane.

• Throttle at the source. Send at most one update every 100 ms, always including the final position (a throttle with a trailing call). On documents with more than 20 people, the server tells clients to slow to one every 500 ms.
• Batch at the server. Instead of relaying each message, the server sends each client one combined presence message every 100 ms with everyone who moved. That's 10 messages per second per client, regardless of the crowd.
• Expire, don't trust. Each client sends a heartbeat every 15 s. The server drops anyone silent for 45 s or whose socket closed, and tells the others. When someone joins, the server sends them the full list.

On screen, remote carets and selections are drawn in an overlay layer above the text, positioned from the model and the layout, never inserted into the editable DOM where they'd confuse the caret and screen readers. Each caret has a name flag that shows while its owner is active and fades after about 3 seconds of no movement. Colors come from a fixed palette of about 10 distinct hues, and the flag always shows the name, so color is never the only clue. With 100 people, show 4 avatars and a "+96" button that opens the full list, and only draw flags for cursors in or near the viewport.

Comments anchored to ranges

A comment belongs to a piece of text: "Friday or Monday?" on the words on Friday. The thread itself (author, body, replies, resolved or not) is ordinary data, so the hard part is the anchor. While the comment is open, people keep typing before, inside, and over the commented words. The highlight must stay on the right words, grow when someone types inside them, and do something sensible when they're deleted.

The naive anchor is a pair of offsets saved with the thread: characters 120 to 129. That's a position, so it goes stale with the first keystroke above it. It's the cursor problem again, except comments last for weeks instead of seconds, and the people who see them may open the document long after the edits happened.

Edge cases that decide the feel

• Typing at the edges. Text typed inside the range joins the comment. Text typed right at its start or end does not, or every word typed after a commented phrase would join the highlight. ProseMirror calls this a non-inclusive mark.
• Creating a comment. The client generates the thread id, sends the mark op through the sync client, and sends POST /docs/:id/comments with the same id. If either fails, a retry with the same id is safe. A mark whose thread doesn't exist is hidden and cleaned up later.
• All anchored text deleted. The thread stays and shows its saved quote with a note that the text was removed. If someone undoes the delete, the text comes back with its mark, and the highlight returns.
• Sidebar layout. Each comment card wants to sit level with its anchor. Sort cards by their anchor's position, and place each one at its anchor's height or just below the previous card, whichever is lower. The selected thread gets its exact spot and the others shift around it. Recompute only for the pages on screen, when their layout changes.
• Live updates. New threads, replies, and resolves arrive on the same WebSocket as small events, separate from document ops, and update the comments store.

Undo and redo in a shared document

In a single-user editor, undo is a stack: push each change, pop to reverse it. In a shared document, the obvious version of that is a disaster. If Ctrl+Z reverses the last change to the document, Alice's Ctrl+Z deletes the sentence Bob just typed. People expect undo to reverse their own last action and nothing else, which is how Google Docs and every serious collaborative editor behaves.

So each person keeps their own stack. That fixes whose change is undone, but not where.

Alice typed quick at 4 in the fox. Bob then typed Note: at 0. Alice's undo should delete quick , but the stored inverse says "delete 6 at 4", and position 4 is now inside Note: . Applied as is, it deletes : the and leaves Notequick fox.

How the stack works

• Inverses. The inverse of an insert deletes the same range. The inverse of a delete inserts the removed text with its marks, which is why delete ops must carry the text they removed. The inverse of a format op restores the previous attributes.
• Grouping. One undo step should match one human action. Consecutive typing joins the current step until a pause of about a second, a cursor jump, Enter, or a formatting command starts a new one. Paste and formatting are always their own steps.
• Transforming. Each remote op is applied to the document and also used to transform every entry on the undo and redo stacks. Mapping 100 entries per op is cheap; keeping thousands is not, hence the cap.
• Redo. Undo pushes the inverse of what it did onto the redo stack, also transformed by later ops. Any new edit by you clears the redo stack, as in every editor.
• Empty undos. If Bob already deleted the text you typed, the transformed inverse deletes nothing. Skip it and undo the next step, so one Ctrl+Z never seems to do nothing.
• Native shortcuts. The browser's own undo must not run. Handle beforeinput events with inputType of historyUndo and historyRedo, plus the undo and redo shortcuts (Ctrl+Z, Ctrl+Shift+Z, and Ctrl+Y, or Cmd on a Mac), and route them to your stacks.

Version history: a log plus snapshots

People want to see the document as it was last Tuesday, find out who removed a paragraph, and restore an old version. The naive way is to save a full copy every few minutes. For a 1 MB document edited every day, that's hundreds of megabytes a year per document. It also loses everything between copies, and a copy can't tell you who changed what.

We already have something better: the server's log of every op, in order, with its author and time. Revision 1,234 is "the document after the first 1,234 ops". The log alone would work, but rebuilding revision 90,000 by replaying 90,000 ops from an empty document is slow. So the server also saves snapshots.

From revisions to a history people can use

• Group revisions. Nobody wants 90,000 entries. Group consecutive revisions into versions by time: start a new entry after about 30 minutes without edits. Each entry lists the people who edited in it.
• Show changes by author. Ops carry their author, so the viewer can highlight inserted text in each author's color and show deleted text struck through, for the range of revisions in one entry.
• Named versions. "Sent to legal" is a label pointing at a revision. It costs one row and protects that revision from compaction.
• Restore as a new revision. Restoring version r computes the op that turns the current document into revision r and applies it as a new revision. Collaborators see it live, it can be undone, and nothing in the log is erased.
• Retention. Keep every op for, say, 30 days. After that, keep the snapshots at version boundaries and named versions, and drop the ops between them. History stays useful while storage stays bounded.

On the client, history is a separate read-only view, such as /d/q3-plan/history?rev=88120. It fetches a snapshot and ops over REST, renders with the same renderer in read-only mode, and loads the version list page by page with a cursor. Keeping it separate means the editor never has to hold the whole history in memory.

Offline editing and catching up

The requirement says someone on a train keeps typing for hours. Good news: the sync client already handles most of this, because ops made while the server is slow simply wait in the pending batch. Offline is the same situation stretched from 300 ms to 3 hours. What's missing is making the waiting ops survive a closed tab, and catching up with everything others did meanwhile.

The naive answers both fail the requirement. Making the editor read-only when the socket drops means no work on the train. Keeping the queue only in memory means a dead battery loses three hours of writing, which is the worst failure an editor can have.

The catch-up, step by step

1. Notice. The socket closes, or a heartbeat gets no reply within 10 s. navigator.onLine is only a hint: it can say online while nothing gets through. The save indicator switches to "Offline, changes saved on this device".
2. Persist. While offline (and online too), write the document at the last acked revision, plus in-flight and pending ops, to IndexedDB. Write within about 500 ms of the last change and again on visibilitychange to hidden, which is the last event a mobile browser reliably fires.
3. Reconnect with backoff. Retry after about 1 s, then 2, 4, 8, up to 30 s, with random jitter so a whole office coming back online doesn't reconnect in the same second.
4. Say hello. Send hello with the document id, the client's rev, its client id, and the seq of the in-flight batch. The server replies with every op after rev.
5. Rebase. If one of the missed ops is the client's own in-flight batch (same client id and seq), the server got it before the connection dropped, so the client treats it as the ack. Every other missed op runs through the same onRemote path, which transforms the in-flight and pending batches. Then the client resends in flight if the server never got it, and sends pending after the ack, as usual.
6. Tell the person. A quiet note such as "You were offline for 3 h. 214 changes from 4 people were merged." with a link to the history view of that period.

When catch-up gets hard

• Too far behind. If the server already compacted the ops after rev, it replies too-far-behind with the latest snapshot. The client computes a diff from its old base document to that snapshot, turns it into ops, and transforms its queue past them. Diffs guess intent, but they keep everyone's text. If even that fails, open the fresh document and show the offline text in a panel to copy from. Never drop it.
• Access removed while offline. The server rejects the queue with forbidden. Keep the local text, explain what happened, and offer to copy or download it.
• Opening documents offline. A service worker caches the app shell, and IndexedDB keeps the 20 most recently opened documents, so the train ride can start with a document that wasn't open. Call navigator.storage.persist() to make the browser less likely to evict that data.
• Several tabs. Each tab is its own client with its own id and its own saved queue. If a tab closed with an unsent queue, the next tab to connect claims it with the Web Locks API (navigator.locks) and sends it, so it's sent exactly once.

Putting it together: the architecture

With the big decisions made, the parts almost name themselves. The rule that shapes every boundary is this: the document model is the only thing that both the screen and the network touch.

Input turns into ops on the model. The renderer draws the model. The sync client sends ops from the model and applies remote ops to it. No part writes to the DOM or the socket except the one that owns it.

Follow one keystroke through the picture. The input layer turns e into a command. The editor core applies insert e at 41 to the model and pushes the inverse onto the undo stack. The renderer redraws one paragraph.

The sync client adds the op to pending and, since nothing is in flight, sends it. About 80 ms later, the collab service saves it as revision 5,012 and broadcasts it. On Bob's screen, his sync client transforms it past his own pending ops, and his renderer redraws the same paragraph.

Data model and interface

Each piece of client data has a natural home. Choosing the wrong one creates bugs: presence in IndexedDB is wasted writes, and queued ops only in memory is lost work. The table lists each entity, where it lives, and why.

The live channel needs to send ops both ways, at high rates, in order, on one connection. That rules out a few familiar options, as the decision shows.

// Client to server
type Up =
  | { type: "hello"; rev: number; clientId: string; inflightSeq: number | null }
  | { type: "op"; baseRev: number; seq: number; ops: Op[] }
  | { type: "presence"; rev: number; anchor: number; head: number }
  | { type: "ping" };

// Server to client
type Down =
  | { type: "ack"; seq: number; rev: number }
  | { type: "remote"; rev: number; author: string; ops: Op[] }
  | { type: "presence"; people: { clientId: string; name: string; color: string; rev: number; anchor: number; head: number }[] }
  | { type: "left"; clientIds: string[] }
  | { type: "comment"; event: "added" | "replied" | "resolved"; threadId: string }
  | { type: "access"; role: "editor" | "commenter" | "viewer" }
  | { type: "error"; code: "too-far-behind" | "forbidden" | "invalid-op"; snapshotRev?: number }
  | { type: "pong" };

GET  /docs/q3-plan                       -> { snapshot, rev, role, title }
GET  /docs/q3-plan/ops?after=5012          -> { ops: [...], rev }  (or 410 if compacted)
GET  /docs/q3-plan/revisions?cursor=abc    -> { versions: [...], nextCursor }
GET  /docs/q3-plan/revisions/88120         -> { snapshot, rev }
POST /docs/q3-plan/comments                -> 201 { threadId }  (Idempotency-Key header)
POST /docs/q3-plan/comments/t-9/replies    -> 201 { replyId }
PUT  /docs/q3-plan/permissions             If-Match: "v7" -> 200 | 412

Large documents and performance

A 300-page document is about 1 million characters, roughly 2,000 paragraphs, and 300 pages of layout. Everything that's fine at 3 pages hurts at 300: rendering every paragraph creates hundreds of thousands of DOM nodes, laying out every page takes seconds, and storing the text as one big string means each keystroke can copy a megabyte. The goal from the requirements: typing on page 250 feels the same as on page 1.

Start with loading. The client fetches the latest snapshot (about 1 MB, around 300 KB compressed) plus the ops after it, while the service worker serves the app shell from cache. It lays out and paints the first two pages first, so the person can read and type within about 2 s, and lays out the rest in small chunks during idle time, yielding to input with scheduler.yield() where supported. The page count in the status bar says "about 300 pages" until that finishes.

The per-keystroke budget

• Incremental layout. An edit relays out only its paragraph. If the paragraph's height changes, later page breaks move, but that work is done lazily for pages off screen.
• Page virtualization. Only the visible pages and one on each side are in the DOM, about 3 of 300. The rest are empty boxes with their computed height, so the scrollbar stays right. When layout isn't done yet, estimated heights are corrected while keeping the reader's position anchored.
• Batch remote ops per frame. If 30 remote ops arrive in one burst, apply them all, then render once in the next requestAnimationFrame. Rendering after each would cost 30 layouts.
• Move work off the main thread. Spell check, word count, and the find index run in a Web Worker that gets text changes per paragraph.
• Bound memory. Cap the undo stacks at 100 steps, keep only the last few hundred ops for mapping late presence, and never load history in the editor.
• Measure in the field. Track the time from beforeinput to the next paint per keystroke, and alert when the 75th percentile passes 16 ms. INP covers the heavier actions like paste.

Permissions and safety

Four roles cover most needs: owner, editor, commenter, and viewer, set per person or for "anyone with the link". The client uses the role to shape the interface: a viewer gets a read-only editor where selecting and copying still work, a commenter gets a read-only editor with the comment button enabled. That's convenience, not security. Anyone can open the browser console and send an op over the socket by hand.

So the collab service checks the role on every op. The socket authenticates with a short-lived token (about 10 minutes, refreshed in the background), and the service keeps each connection's current role in memory. There's one subtle case: a commenter must be allowed exactly one kind of document op, adding or removing a comment mark, because comment anchors live in the document. Anything else from a commenter is rejected with forbidden.

• Role changes mid-session. When an owner turns Bob from editor into viewer, the server sends him an access message and rejects his later ops. His client switches to read-only and shows his unsent text in a panel to copy, instead of silently dropping it.
• Access removed. The server closes the socket. The client deletes its IndexedDB copy of that document, because an offline copy is still a copy. Do the same for every cached document on sign-out.
• Paste is untrusted input. Pasted HTML is parsed into the model's own blocks and marks, so a script tag or an onerror attribute has nowhere to live. Link marks accept only https, http, and mailto URLs.
• Op limits. The server rejects ops larger than about 1 MB and clients sending far beyond human typing speed, which protects the document's owner process from a buggy or hostile client.

Accessibility in a live editor

An editor is a text box that thousands of people live in all day, including people who use screen readers, switch devices, or only a keyboard. Choosing a model-first editor with contenteditable as the surface pays off here: the DOM holds real text, real headings, real lists, and real tables, so screen readers can read and edit it with their usual commands. Render semantic elements (h1 to h3, ul, ol, li, table), and give the editable root role="textbox", aria-multiline="true", and a label from the document title.

Collaboration adds a problem single editors don't have: the text changes while someone reads it. Announcing every remote keystroke would make the document unusable with a screen reader. The rule is restraint: remote edits are applied silently, the local caret never moves because of them, and the person can ask for what's happening instead of being told constantly.

• Remote cursors are decoration. Mark the overlay aria-hidden="true". Provide a keyboard shortcut that announces who's in the document and where ("Bob is in the heading Budget"), and a collaborator list that's reachable by Tab.
• Rare, polite announcements. Use one aria-live="polite" region for joins and leaves (batched: "2 people joined"), going offline, coming back, and merge notices. Never announce "Saving..." on every keystroke.
• A way out of the text. Tab inside a list indents it, so focus can get trapped. Document shortcuts to move focus to the menus, the toolbar, and the comments panel. The toolbar follows the WAI-ARIA toolbar pattern: one Tab stop, arrow keys inside.
• Comments by keyboard. A shortcut adds a comment on the selection. When the caret is in commented text, the comment is reachable with one more shortcut and announced as "has comment".
• Not color alone. Every remote cursor and history highlight comes with a name. Respect prefers-reduced-motion by not animating remote cursors as they glide.
• Canvas needs a twin. If the renderer ever moves to canvas, screen readers see an image. Keep an off-screen accessible text layer in sync, which is the reason Google Docs has a separate screen reader support setting.

Running it in the interview

This problem is too big to cover evenly in 60 minutes, and interviewers know it. What they watch for is whether you find the core (concurrent edits on copies that can't wait for each other), solve it with a real mechanism, and then go deep where they point you. The plan below spends the most time on the part that only this problem has.

1. Minutes 0 to 5: scope. Ask how many people edit at once, how big documents get, whether offline matters, and what a document contains. Write down 16 ms, 300 ms, and 100 editors.
2. Minutes 5 to 12: the core problem. Draw two copies of buy milk diverging. Name ops as the unit of change, and walk through why last write wins, locks, and version checks fail for body text.
3. Minutes 12 to 27: merging. Draw the transform diamond, work one example out loud, then the three-state client and the server's revision log. Compare with CRDTs in two sentences and say why you chose one.
4. Minutes 27 to 37: architecture and model. The parts table, the model as blocks and runs, model-first contenteditable, and the message types.
5. Minutes 37 to 52: deep dives. Let the interviewer pick: cursors, comments, undo, history, offline, or big documents. Each has a mechanism in this guide that you can explain in about 5 minutes.
6. Minutes 52 to 60: wrap-up. Permissions on the server, accessibility, and what you'd measure. End by naming the riskiest part, the transform functions, and how you'd test them.

Draw in a fixed order so the board tells the story: first the two diverging copies, then the diamond next to them, then the client's three states with the server's log, and only then the boxes of the architecture. Each later topic (cursors, comments, undo, offline) is then a short arrow back to the diamond: "this is a position, so it gets transformed too".

Follow-up questions and strong answers

• "Why not a CRDT?" Both work. We need a server anyway for permissions, history, and 100 editors, and OT keeps the model free of per-character metadata. A CRDT wins for days offline or peer-to-peer.
• "What if the server crashes after receiving an op?" The server acks only after the op is durably in the log. A client without an ack resends with the same seq, and the new owner process either applies it or re-acks it.
• "How do you test this?" Fuzz the transforms with random op pairs and check both paths match. Then run simulated clients with random delays and disconnects and assert every copy ends identical.
• "What about 1,000 viewers on a company announcement?" Viewers don't send ops, so the owner process isn't the bottleneck. Fan the op stream out through a separate broadcast tier, and cap presence to a viewer count instead of 1,000 cursors.
• "Someone pastes 50 pages." It's one op, under the 1 MB limit, applied to the model at once. Layout and rendering run in chunks, with the visible page drawn first, so the paste stays within the 200 ms INP budget.
• "How would suggestion mode work?" Suggestions are ops stored with a "suggested by" mark instead of applied text. Accepting one is a new op that clears the mark; rejecting one is a new op that removes the text.