How to design a Collaborative Editor (Google Docs)

What a strong answer covers

• Traffic is high-rate in both directions, so a persistent full-duplex channel fits.
• A single connection preserves the order of a client's own ops; separate requests do not.
• Names what the choice costs: reconnection, heartbeats, deploy handling, routing.Supporting

What a strong answer covers

• Each document needs one authority assigning order; clocks cannot provide it.
• Partitioning by document gives each its own sequencer while documents scale out independently.
• Names what this creates: routing, hot documents, and keeping ownership unique during moves.Supporting

Tradeoffs

What a strong answer covers

• Concurrent edits to the same region are normal, so the merge must preserve both rather than choose one.
• Explains the mechanism: transformation against concurrent ops (OT) or commutative ops via stable identities (CRDT).
• Addresses offline: long divergence is expensive for OT and natural for CRDTs.

In this order

1. 1Alice's client applies the op to her local document immediately
2. 2Client gives the op an id (client id + counter) and adds it to the pending buffer
3. 3Client sends the op with the last sequence number it has seen
4. 4Owner checks permissions and integrates the op into the in-memory document
5. 5Owner appends the op to the log with the next sequence number; the batch commits
6. 6Owner acks to Alice with the sequence number
7. 7Alice's client removes the op from its pending buffer
8. 8Owner broadcasts the sequenced op to the document's other clients
9. 9Bob's client integrates the op and advances its last-seen sequence

What a strong answer covers

• Presence describes the present; losing it on a crash costs nothing because clients re-announce.
• It must expire automatically (heartbeat plus TTL), or disconnected users linger as ghosts.
• Cursor updates can be throttled, coalesced and sent at-most-once, since only the latest matters.Supporting

What the fix has to do

• Ack only after the op is durably persisted; batching is fine if acks wait for the batch.
• Clients keep ops until acked and resend on reconnect; the op id makes the resend idempotent.
• On reconnect, the server compares the client's last seen position with the log and forces a resync if the client is ahead.
• Broadcasting before durability let other clients see ops that were then lost.Supporting

Reference implementation

class DocClient {
  lastSeq = 0;
  pending: Op[] = [];
  attempt = 0;

  onReconnect(socket: Socket) {
    this.attempt = 0;
    // The log is the buffer: ask for everything after our position,
    // and offer every op we still hold. Same ids as before.
    socket.send({ type: "hello", lastSeq: this.lastSeq, pending: this.pending });
  }

  onDisconnect() {
    const delay = Math.random() * Math.min(30_000, 500 * 2 ** this.attempt++);
    setTimeout(() => this.connect(), delay); // full jitter
  }

  onServerMessage(msg) {
    switch (msg.type) {
      case "op": {
        if (msg.op.seq <= this.lastSeq) return;            // duplicate delivery
        if (msg.op.seq !== this.lastSeq + 1) return this.requestFrom(this.lastSeq);
        const mine = this.pending.findIndex((p) => p.id === msg.op.id);
        if (mine >= 0) {
          // Our own op, sequenced (its ack may have been lost).
          this.pending.splice(mine, 1);
        } else {
          // Rebase: integrate the remote op, transforming pending ops past it
          // (OT), or merging by identity (CRDT, where order does not matter).
          this.doc.integrateRemote(msg.op, this.pending);
        }
        this.lastSeq = msg.op.seq;
        return;
      }
      case "ack": {
        this.pending = this.pending.filter((p) => p.id !== msg.opId);
        // lastSeq advances when the sequenced op itself arrives in order.
        return;
      }
      case "resync": {
        // The server's history differs from what we saw. Its log wins;
        // our unacknowledged work is re-applied on top.
        this.doc = Doc.from(msg.snapshot);
        this.lastSeq = msg.seq;
        for (const op of this.pending) this.doc.applyLocal(op);
        return;
      }
    }
  }
}

What a strong answer covers

• On reconnect the client sends its last seen sequence and receives missed ops from the log, rather than relying on server memory.
• Pending ops are resent with their original ids, so the server deduplicates any it had already sequenced.
• Missed remote ops are integrated before or alongside the pending ops (transform or CRDT merge), so local edits are rebased rather than overwritten.
• Remote ops are applied in sequence order; duplicates (seq <= lastSeq) are ignored.
• Handles a resync by replacing state with the snapshot and re-applying pending ops on top.Supporting
• Reconnects use exponential backoff with jitter.Supporting

What a strong answer covers

• Sequencing must stay single-writer, but fan-out delivery can be distributed.
• Per-connection buffers must be bounded; slow clients fall back to catching up from the log.
• Batching or coalescing reduces per-message overhead.Supporting

What a strong answer covers

• A snapshot must record exactly which sequence number it reflects, so replay starts at the next op with no gap or duplicate.
• The log after the latest snapshot remains essential for catch-up and correctness.
• Older history can be compacted into coarser snapshots for the version sidebar.Supporting

Reference answer

What a strong answer covers

• Convergence: ops are merged by a convergent algorithm (server-ordered OT or CRDT) and applied idempotently by op id.
• One history per document: a single owner with an epoch-fenced lease and a unique (doc, seq) constraint.
• Durability: acks are sent only after commit, and clients hold ops until acked and resend them on reconnect.
• Names what would break each, e.g. acking before commit, a second sequencer without fencing, a client losing its pending buffer before reconnecting, a merge bug.
• Distinguishes what is not guaranteed: intent preservation, latency during handoffs, presence accuracy.Supporting