Collaborative Document Editing (Google Docs) System Design Interview Guide

Most system design questions are about moving data between machines. This one is about something narrower and stranger: keeping a single mutable sequence identical on every machine while several people rewrite it at once, without ever taking a lock and without ever making a typist wait for the network.

The hard problem sits in one sentence. Every client edits a document that is already out of date by the time the edit is expressed. You typed a character at offset 42, but in the milliseconds while your keystroke was in flight, a colleague deleted a paragraph above you, and offset 42 no longer means what you meant. Applying edits in arrival order produces different documents on different screens. Applying them in timestamp order produces garbled text. Locking a paragraph produces a product nobody wants to use. The interview is asking how you get convergence (everyone ends at the same bytes) and intention preservation (the character lands next to what the user was looking at) out of a system where no client ever has a current view.

Notice what the question is not about. It is not file transfer, not chunking, not delta sync of opaque blobs. Those problems are covered in designing a file storage service, where the unit of conflict is a whole file and the acceptable resolution is "keep both copies". Here the unit of conflict is a character offset and "keep both copies" is a product failure. It is also not ordered message delivery to a room, which is the chat system question: chat messages are independent and append-only, so ordering them is enough, whereas document operations are interdependent and must be rewritten against each other before they can be applied. CRDTs make a one-line appearance in the key-value store guide as a way to reconcile two versions of one value; this guide is about the much harder case where the value is an ordered sequence and the conflict is positional.

Two clarifying questions change the whole design and belong in the first minute. Is there a trusted server? If the answer is yes, a central total order is available for free and Operational Transformation becomes tractable; if the product is local-first or peer-to-peer, it is not, and §5 resolves differently. How long may a client be offline and still merge silently? That single number sets the operation retention window, which sets the compaction schedule, which sets the storage bill.

Functional requirements

Explicitly out of scope: document rendering and pagination, export to PDF/DOCX, spell check and the ML suggestion stack, and the document-list surface (search, folders, sharing UI). All are real systems; none of them touch the convergence problem, and an interviewer who wanted them would have asked for Drive.

Non-functional requirements

The usual dimensions do not bind here. Document text is tiny, so storage of the current state is uninteresting. Reads are not amplified by a social graph, so there is no fan-out-on-write explosion. What actually constrains this system is the product of three things: how many editors are connected at once, how many operations each of them emits, and, decisively, how many of them are in the same document.

The third factor is the one that shapes the section, because it behaves differently from everything else. Operations for a document must be totally ordered, so one server owns the document and every editor of it connects there (§9). A document is therefore a shard you cannot split. The fleet is sized by aggregate connections and scales horizontally without drama; the product limit is sized by whatever a single machine can do for the busiest document, and no amount of hardware changes that. So the estimate has two halves, and the interesting half is the small one.

Concurrency is derived with Little's Law: the number of sessions in flight equals the arrival rate multiplied by the average session duration (L = λW). It is the only way to get from "sessions per day", which product teams know, to "simultaneous connections", which is what you provision.

The shape of this system is unusual in one respect, and the diagram reads better after naming it: there is a stateful, singular authority per document sitting in the middle of an otherwise stateless fleet. Most designs in this series push state down into a database and keep the serving tier interchangeable. Here the serving tier holds the materialised document and the current revision number in memory, because transforming an operation requires knowing every operation committed since the operation's base revision, and paying a database round trip per keystroke is not compatible with §2's propagation budget.

What each component does

Editor client. Holds the full document model in memory, applies the local user's edits immediately, and keeps two buffers: the operation currently in flight to the server, and everything typed since, composed into a single pending operation. The non-obvious constraint is that it must be able to transform an incoming remote operation against both buffers before applying it — the client runs the same transform code as the server, and a mismatch between the two implementations is a divergence bug.

Edge gateway. Terminates TLS, authenticates the connection once, and holds the WebSocket. It is the only component that is genuinely stateless and horizontally trivial. The constraint is connection budget rather than CPU: at §3's defaults it is holding 3.13 M idle-ish sockets, which is a memory and file-descriptor problem, not a throughput one.

Session router. Answers one question — which session server currently owns this document — and hands out the lease that makes the answer authoritative. It is backed by a strongly consistent store, because a stale answer here does not cause a slow request, it causes two servers to accept conflicting writes. This is the component most candidates skip and the one that separates a design that works from one that only works when nothing crashes.

Session server. The document authority. It holds the materialised document, the current revision number, and a window of recent operations; it transforms each arriving operation against everything committed since that operation's base revision, appends the result to the log, and broadcasts. Its constraint is that it is the single point through which all of a document's concurrency passes, which is why §3's quadratic fan-out lands entirely here.

Replica session servers. Subscribe to the committed operation stream for hot documents and serve read-only viewers. They never accept operations, so they need no lease and no transform engine, which is precisely why they scale freely where the authority does not.

Operation log. An append-only, per-document, revision-ordered log. It is the source of truth; the document is a derived view of it. Its constraint is write amplification of a different kind than usual — the volume is small per write but enormous in aggregate (§3's 13 TB/day), and it is the reason history is tiered rather than kept.

Snapshot store. Periodically materialised document states that bound how many operations a cold open must replay. The constraint is that a snapshot must be taken at an exact revision boundary and labelled with it, or replay produces a document that is subtly wrong rather than obviously broken.

Presence store. Cursors, selections and the collaborator list, with a short TTL. It deliberately bypasses the authority and the log: presence must not be durable, must not be ordered, and must not be replayed on reconnect. Mixing it into the operation stream is a common design error that makes the log an order of magnitude larger for data nobody will ever want to read twice.

Metadata & ACL service. Owns document metadata, sharing state and permissions, and publishes revocations. The constraint is that it must be able to reach live sessions, not just the open endpoint, because a session outlives the permission that created it (§10b).

Async consumers. Version history assembly, search indexing, and export/render all read the operation log rather than querying the authority. Keeping them on the log side means a slow indexer can never add latency to a keystroke.

Architectural rationale

How real systems decide this

This is the one place in the design where two genuinely different algorithms solve the same problem, and where a candidate who names one without being able to describe the other is immediately readable as having memorised rather than understood. Both achieve convergence; they disagree about where the ordering comes from.

Neither can be described until the document is defined, because both operate on whatever position 812 refers to. The model that makes OT tractable is a flat sequence of characters with formatting carried as ranges over it rather than as nested markup — the shape Quill's delta format and Google's own wire format both use. A paragraph break, a list item, a table cell boundary: each is a single marker character in the sequence, so structure lives in the same coordinate space as text and a position is always one integer. That is what lets a transform be a few lines of arithmetic.

A genuine tree — nodes, children, moves — is where OT stops being tractable. Transforming a move against a concurrent move of an ancestor has no position arithmetic to fall back on, and the published transform functions for trees are both harder to prove correct and far rarer in production than the flat-sequence ones. Real editors keep the sequence and pay for it on the render side, rebuilding the tree on every change.

Operational Transformation puts the ordering in a server: operations are expressed against numeric positions, and a central authority rewrites each arriving operation so that it means the same thing against the current document as it did against the stale one. A sequence CRDT puts the ordering in the data: every character carries a globally unique, immutable identifier and a pointer to what it was inserted after, so any two replicas that have seen the same characters agree on their order without anyone adjudicating.

Walking the example through OT

Start with "ABC" at revision 5, which both clients have. A inserts "X" at position 1 and immediately renders "AXBC" locally. B deletes position 0 and immediately renders "BC". Neither has seen the other. Both send their operation stamped with base revision 5.

Two things in step 4 carry the whole design. First, the client runs the transform too — it must rewrite incoming remote operations against its own unacknowledged ones, which is why the transform code has to be shared or bit-for-bit equivalent between client and server. Second, neither user ever saw their own edit undone or re-ordered; the characters they typed stayed where they typed them, and only the other person's edit moved. That is intention preservation, and it is what distinguishes this from a merge.

function transform(incoming, applied) {
  // A format changes no positions, so anything but another format passes through.
  if (applied.type === 'format' && incoming.type !== 'format') return incoming;

  // insert vs insert
  if (incoming.type === 'insert' && applied.type === 'insert') {
    if (incoming.pos < applied.pos) return incoming;
    if (incoming.pos > applied.pos) return shift(incoming, applied.text.length);
    // Same position. Break the tie with a total order on site id so that
    // both sides make the identical choice; without this, TP1 fails and
    // one client renders "XY" while the other renders "YX".
    return incoming.site < applied.site
      ? incoming
      : shift(incoming, applied.text.length);
  }

  // insert vs delete
  if (incoming.type === 'insert' && applied.type === 'delete') {
    if (incoming.pos <= applied.pos) return incoming;
    if (incoming.pos >= applied.pos + applied.len) return shift(incoming, -applied.len);
    return { ...incoming, pos: applied.pos };   // the anchor text was deleted
  }

  // delete vs insert
  if (incoming.type === 'delete' && applied.type === 'insert') {
    if (incoming.pos >= applied.pos) return shift(incoming, applied.text.length);
    if (incoming.pos + incoming.len <= applied.pos) return incoming;
    return splitAround(incoming, applied);      // the insert landed inside the range
  }

  // format vs insert: the styled range shifts if the insert lands before it and
  // splits if it lands inside, so one fmt can become two
  if (incoming.type === 'format' && applied.type === 'insert') {
    return incoming.pos >= applied.pos
      ? shift(incoming, applied.text.length)
      : splitAround(incoming, applied);
  }

  // format vs delete: clip the range to whatever survives; may become a no-op
  if (incoming.type === 'format' && applied.type === 'delete') {
    return clipRange(incoming, applied);
  }

  // format vs format: both apply unless they set the SAME attribute to different
  // values on overlapping ranges, which is the one genuine conflict here
  if (incoming.type === 'format' && applied.type === 'format') {
    return conflictsOn(incoming, applied) && incoming.site > applied.site
      ? dropAttrs(incoming, applied.attrs)
      : incoming;
  }

  // delete vs delete: subtract the overlap; the result may be a no-op
  return subtractOverlap(incoming, applied);
}

Why this design picks OT

The decisive point is narrower than "OT is better". Server-authoritative OT in the Jupiter model only needs transform property TP1 — that transforming two concurrent operations against each other yields the same document in either application order. Decentralised OT, where operations can arrive along different paths, additionally needs TP2, a much stronger condition about transforming against sequences of operations, and TP2 is where published OT algorithms have repeatedly been shown incorrect. Keeping a single server in the path deliberately stays inside the tractable half of OT. A CRDT would be the right answer for a local-first editor with no trusted server, for peer-to-peer sync, or for unbounded offline work — and the cost of that choice is paid in per-character metadata and coarser history.

The consumer of this API is not a script making requests; it is a long-lived client holding mutable state that must be reconciled after every interruption. So the interesting surface is not a list of endpoints but a connection lifecycle: what a client is told when it joins, what it may send, what it is promised about ordering, and how it recovers when the connection drops mid-edit. REST exists here only for the things that happen outside an editing session.

Joining a document

// Server's first frame, before any operation is accepted.
{
  "type": "session.init",
  "session_id": "s_7f3a91",         // identifies this connection in every later frame
  "revision": 4172,                 // the revision the snapshot below corresponds to
  "snapshot_url": "https://…/doc/d_881/snapshot/4172",
  "role": "editor",                 // editor | commenter | viewer, from the ACL
  "acl_version": 19,                // bumped on any permission change (§10b)
  "transform_version": 3,           // negotiated; see §10
  "collaborators": [
    { "session_id": "s_2b10", "user_id": "u_44", "color": "#0e7c6a" }
  ]
}

The snapshot is fetched over plain HTTP rather than streamed down the socket, because it is large, cacheable by the client, and immutable at that revision — three properties the operation channel does not have. The client applies the snapshot, sets its local revision to 4172, and only then begins sending.

The operation envelope

{
  "type": "ops",
  "client_op_id": "s_7f3a91:118",   // idempotency key: session_id + monotonic counter
  "base_revision": 4172,            // what this client last saw
  "ops": [
    { "t": "ins", "p": 812, "s": "convergence" },
    { "t": "del", "p": 940, "n": 3 },
    { "t": "fmt", "p": 812, "n": 11, "a": { "bold": true } }
  ]
}

// Server, on success — durable before this frame is sent (§6):
{ "type": "ack", "client_op_id": "s_7f3a91:118", "revision": 4173, "checksum": "b41e…" }

// Server, to every other session on the document. The frame carries a revision
// *range*, because broadcast batching (§9) collapses several commits into one frame:
{ "type": "remote", "from_revision": 4173, "revision": 4173,
  "entries": [ { "revision": 4173, "session_id": "s_7f3a91",
                 "ops": [ /* transformed against everything committed since 4172 */ ] } ],
  "checksum": "b41e…" }

Three guarantees need stating explicitly, because an interviewer will ask for exactly these. Ordering: the server's revision number is the total order, and a client must apply remote frames contiguously: from_revision must equal its local revision plus one. A frame that skips ahead means a lost frame and triggers resume, not a best-effort apply. The range form is load-bearing rather than cosmetic — under batching a single frame carries revisions 4,174 through 4,180, and a frame naming only its highest revision would be indistinguishable from a dropped one. Each entry keeps its own session_id, because a batched frame routinely spans several authors. Delivery: at-least-once from the client, deduplicated to exactly-once by client_op_id for as long as the dedup index retains it (§7), which is what makes blind retry after a reconnect safe. Per-session FIFO: one client never has two operations in flight (§6), so its own operations can never be reordered relative to each other.

Comments and suggestions ride the same socket as a separate comment frame — create, reply, resolve — with its own ack. They are deliberately not ops frames: a comment does not change the text, so it takes no revision number and never queues behind the one-in-flight rule. Its anchor is transformed forward by the same functions the text uses (§7).

Losing and regaining the connection

{
  "type": "resume",
  "doc_id": "d_881",
  "last_revision": 4173,
  "pending": [ { "client_op_id": "s_7f3a91:119", "base_revision": 4173, "ops": [ … ] } ]
}

// Happy path — the gap is still inside the retained operation window:
{ "type": "resume.ok", "revision": 4190,
  "ops": [ /* revisions 4174…4190, in order */ ] }
// The client transforms its pending ops against these, then re-sends them.

// The gap has been compacted away (beyond the 24 h window of §2):
{ "type": "resync", "revision": 4190,
  "snapshot_url": "https://…/snapshot/4190",
  "reason": "revision_too_old" }
// The client rebuilds from the snapshot; its pending edits become a
// reviewed merge rather than a silent transform (§10).

Errors, limits and back-pressure

Back-pressure has a defined shedding order, and stating it is what separates this from a protocol sketch. Under load a session server first drops presence frames, then coalesces remote frames into at most one per client per 50 ms, and only then begins rejecting ops with rate_limited. Edits are sacrificed last because they are the only thing that is durable.

The REST surface around the session

Everything the system does in steady state is one path repeated a million times a second. It is worth tracing once in full, because the ordering of two steps in the middle — durably appending before broadcasting — is the only thing standing between this design and a document that can un-type itself.

Before the trace, one rule that shapes it: a client holds at most one operation in flight. Everything typed while an operation is unacknowledged is composed into a single pending operation that goes out when the acknowledgement arrives. This is the Jupiter model, and it buys two things — the server never has to transform against an unbounded backlog from one client, and the client's state machine reduces to two buffers (sent, pending) rather than an arbitrary queue.

The branches that matter

There are only four entities that matter: the operation, the snapshot, the document (metadata and permissions) and presence. What is unusual is how differently they are used. Operations are written at a million per second and read almost never. Snapshots are written rarely and read on every cold open. Metadata is read on every open and written by humans clicking Share. Presence is written constantly and must never be persisted at all. Four access profiles that extreme do not belong in one store.

Two observations out of that table determine everything below. First, every hot-path access is keyed by a single doc_id and none of them crosses documents. That makes doc_id the partition key in every store on the edit path, guarantees that a document's data is co-located with its owning session server's reads, and means the document list — the one cross-document query — has no business being in the same store. Second, operations are immutable and strictly ordered, and are never updated or individually deleted. A store that only needs append and range-scan-within-partition is a log, and choosing a general-purpose table with secondary indexes for it buys flexibility nothing will use.

Operation log

document_ops
  PRIMARY KEY ((doc_id), revision)     -- partitioned by document, clustered ascending

  doc_id         uuid
  revision       bigint      -- assigned by the owning session server; gapless
  lease_epoch    bigint      -- fencing token; append rejected below the current epoch (§9)
  session_id     text
  user_id        uuid
  client_op_id   text        -- dedup key; unique with session_id
  base_revision  bigint      -- what the author saw when they typed
  ops            blob        -- compact encoding, ~120 B average (§3)
  created_at     timestamp

Snapshots

document_snapshot
  PRIMARY KEY ((doc_id), revision DESC)   -- latest first; point read is the common case

  body        blob        -- compressed materialised document at exactly this revision
  op_count    int         -- operations folded since the previous snapshot
  checksum    text        -- must match the rolling checksum carried on revision N (§10)
  created_at  timestamp

The checksum column is the quiet one, and it is worth being precise about what it can and cannot catch. A snapshot is produced by folding the committed operations, which is the same fold the owning session server performs in memory. A mismatch is therefore direct evidence that the authority's memory and the log have diverged: an operation broadcast but never appended, a lost or reordered append, or storage corruption — caught by a background job rather than by a user noticing their document is wrong.

What it cannot catch is a transform bug. The committed operation is already the transformed one, so a wrongly transformed operation is written once and folded identically by both sides; the checksums agree and the document is quietly wrong. Transform bugs surface only in the client comparison (§10), because a client's document is a genuinely different computation — remote operations transformed against its own pending buffer, which the server never did. The two checks are complementary, and an answer that offers only the server-side one has not covered the failure it claims to.

Metadata, permissions and presence

documents                              -- relational store, indexed for the doc picker
  doc_id, title, owner_id, created_at,
  current_revision, snapshot_revision,
  state ENUM('active','trashed','purging','purged'),
  acl_version, home_region

document_acl
  PRIMARY KEY ((doc_id), principal_id)   -- principal = user, group, or link token
  role ENUM('owner','editor','commenter','viewer'),
  granted_by, expires_at, link_scope

-- Presence is not a table. It is a Redis hash with PER-FIELD expiry:
HSET     presence:d_881 s_7f3a91 '{"u":"u_44","anchor":812,"head":830}'
HEXPIRE  presence:d_881 45 FIELDS 1 s_7f3a91   -- Redis 7.4+; refreshed by a 15 s heartbeat
EXPIRE   presence:d_881 3600                   -- key level; only reclaims fully idle documents

The per-field expiry is load-bearing, not a refinement. EXPIRE applies to the whole hash, and every live editor's heartbeat refreshes it — so on a document with two editors, one browser dying leaves its field in the hash indefinitely, kept alive forever by the survivor's heartbeat. The key-level TTL only reclaims documents that go completely idle. HEXPIRE (Redis 7.4+) is what actually makes a dead session disappear. Before 7.4 the equivalent is to carry the heartbeat timestamp inside each field's JSON and have the session server filter stale fields on read, pruning them opportunistically; a key-level TTL cannot express per-session liveness at all.

Splitting documents off into a relational store is deliberate. The document picker needs queries the edit path never issues — by owner, by folder, by last-opened, by title prefix — and those require secondary indexes that would be dead weight on a log optimised for partition-local appends. It also means a slow picker query cannot contend with an operation append, which matters more than the small cost of a second store.

Comment and suggestion anchors

A comment is attached to a range of text, and that text moves every time anyone types above it. The anchor is therefore not a pair of offsets; it is a pair of offsets plus the revision they were taken against, and the same transform functions that move operations forward move anchors forward too.

comments
  PRIMARY KEY ((doc_id), comment_id)
  author_id, body, created_at, parent_comment_id,
  anchor_start, anchor_end,              -- offsets into the document
  anchor_revision,                       -- the revision those offsets are valid against
  state ENUM('open','resolved','orphaned')

On load, the session server transforms each anchor from anchor_revision to the current revision through the log, then rewrites the row so the next load starts closer. The interesting case is when a delete covers the whole anchored range: the transformed anchor collapses to zero width, and the comment becomes orphaned rather than disappearing. Orphaned comments still render in the sidebar with their quoted text, detached from the body — which is what users expect, and what a naive offset-only anchor cannot express.

Suggestions are the same mechanism pointed at the operation log instead. A suggested edit is a real operation, tagged with a suggestion_id and committed to the log like any other, but the snapshot builder skips it: it is visible as an overlay and not folded into the materialised document until someone accepts it. Accepting appends nothing new — it clears the tag and the next snapshot includes the operation. Rejecting appends the inverse, exactly as undo does (§5). This is why suggestion mode does not need a second document or a branch: the log already orders everything, and the tag decides what the snapshot sees.

The usual caching section does not apply here, and saying why is more useful than forcing one. A document body is mutable and per-user authorised, which disqualifies every shared cache: an edge node cannot hold it because it would serve stale text, and it cannot hold it because the next requester may not be allowed to see it. There is exactly one shared cache in this design, and it is the session server that already owns the document.

What replaces the cache hierarchy is a read-path reconstruction problem. §7 made the operation log the source of truth, which means "open this document" is not a row fetch but a fold over history. Left alone that cost grows without bound, so the real subject of this section is how many operations an open is ever allowed to replay, and what it costs when the answer is zero.

The last row is the nuance to state out loud in an interview. Embedded images are content-addressed immutable blobs and belong on a CDN; the document text never does. Candidates who put "CDN" in front of the whole system are describing a different product; candidates who say "no CDN, it's all dynamic" have given up an easy 80% of the bytes.

The cold-open budget

Snapshot cadence, and why 1,000

A snapshot is written every 1,000 revisions or 30 minutes of active editing, whichever comes first. Both bounds exist because either alone fails: revisions alone leave a document edited once a day replaying a week of scattered operations, and time alone leaves a document under heavy collaborative editing accumulating 20,000 operations in half an hour.

The number itself falls out of two costs pulling in opposite directions. Replaying 1,000 operations costs about 5 ms and reads 120 KB of log — negligible, so the replay side would happily accept 10,000. The snapshot side will not: a 200 KB materialised document, stored compressed at about 60 KB, rewritten on every revision at §3's 1.25 M operations per second would be 75 GB/s of snapshot writes, which is absurd by three orders of magnitude. At one snapshot per 1,000 revisions it is 75 MB/s, which is ordinary. 1,000 is simply where the replay cost is still invisible and the write amplification has become affordable.

Invalidation, which mostly is not a problem

This is where the single-authority choice pays off in an unexpected place. Because exactly one server may write a document, and every reader of the live document is connected to that server or to a replica fed by it, there is no cache coherence problem in steady state. Nothing can be stale relative to anything else, because there is only one writer and one materialised copy.

That leaves two events that genuinely invalidate, and neither is a TTL:

Scaling this system is not the usual exercise of adding replicas until the load fits, because the thing that binds (§3) is a single document on a single machine. The work divides into three genuinely different problems: keeping exactly one owner per document while machines fail, making the busiest document survivable on one machine, and keeping the history affordable.

Ownership: leases and fencing

A document is assigned to a session server by a lease recorded in a strongly consistent store — 10 second TTL, renewed every 3 seconds. Consistent hashing over the server pool decides which server asks for the lease; it never decides who holds it. That distinction is the whole mechanism: hashing is a local computation that different clients can disagree about during membership churn, while a lease is a fact serialised by one store.

A planned handoff — a deploy, or a rebalance — does not wait for the TTL. The outgoing owner stops accepting operations, flushes everything pending to the log, records the final revision, releases the lease, and closes its sessions with 4503. Clients reconnect, resume from their last revision against the new owner, and the whole thing costs a few hundred milliseconds during which typing is buffered locally rather than lost. An unplanned handoff costs the lease TTL instead: up to 10 seconds of buffered typing, after which the new owner rebuilds from the latest snapshot plus the log tail and clients resume against it.

Surviving the busiest document

§3 showed the problem: 50 editors on one document produce ~980 broadcast messages per second on one machine, and the relationship is quadratic. Three levers apply, cheapest first — though cheapest is very nearly the reverse of most effective:

Batching deserves a caveat, because it is the lever candidates reach for first and the one that does least. At §3's defaults each editor already receives only 0.4 × 49 ≈ 20 messages per second, so a 50 ms frame barely clamps anything — it takes the coral number from 980 to roughly 625/s. The clamp engages properly only above ~51 editors, and at the 100-editor cap it is a 2× saving, 3,960 down to 2,000. It is a real lever against a burst where everyone types at once and a weak one against editor count, which is the opposite of how it is usually offered.

Keeping history affordable

13 TB/day of raw operations (§3) cannot be retained at full fidelity, and does not need to be: nobody scrubs version history keystroke by keystroke. History is therefore tiered, and each tier trades resolution for size.

Geography

Every document has a home region, and the authority lives there. An editor in Singapore on a document homed in Iowa pays the round trip — roughly 190 ms, against §6's 30 ms per-hop assumption — which lands propagation near 285 ms. That is not catastrophic; it is a miss on the 200 ms NFR that no amount of tuning inside the region recovers. There are only two real responses, and multi-master is not one of them: OT needs a single total order, so replicating write authority across regions is not a tuning decision but a change of algorithm to a CRDT.

The failures worth discussing here are the ones that produce wrong documents rather than unavailable ones. An editor that is down is obvious, recoverable, and boring; an editor that quietly gives two people different text is the failure this entire architecture is arranged to prevent, and the one an interviewer will push on.

The trust problems in a collaborative editor are not the usual ones. There is no public content to moderate and no money to defraud; what there is instead is a long-lived session holding privileged state, a sharing model that most breaches come through, and a history that remembers everything a user ever typed including what they deleted.

1. Permissions change while the session is open

Checking access when a document is opened is checking it at the wrong time. An editing session lasts fifteen minutes on average (§3) and can last hours, and access revocation is usually urgent precisely because someone is currently in the document.

The mechanism: every session carries the acl_version it was authorised under. The metadata service bumps that version on any permission change and pushes the change to the owning session server, which closes affected sessions with WebSocket code 4403 and discards their pending operations rather than committing them. Operations already committed stay committed — revocation is not retroactive, and claiming otherwise would require rewriting the log. The push path is the same one used for ownership handoff (§9), so this costs no new infrastructure.

Interview probe, L5/L6: "I remove someone's access while they're typing. What happens to the sentence they're halfway through?" The answer has to include that their unacknowledged operation is dropped and their already-committed text stays.

2. Sharing links are the actual attack surface

"Anyone with the link can edit" is how most real document leaks happen, and the design decision that matters is what the link contains. A link token must be an opaque, independently revocable credential stored as its own principal row in document_acl (§7) — never a value derived from doc_id, never a signed capability that cannot be withdrawn without rotating a key.

That gives the properties that matter: a link can be revoked without touching any user's access, it can carry an expiry and a domain restriction, and its usage is attributable because access via a link token is distinguishable in the audit trail from access by an identified user. Detection follows from that attribution — a link token being redeemed from dozens of unrelated networks within an hour is the signature of a link that has escaped into a mailing list or a search index.

Interview probe, L6: "A link to a confidential document was posted publicly. What can you do, and what can you not undo?" Revoke the token, enumerate the accesses from the audit trail — but the copies people already made are gone, which is the correct second half of the answer.

3. Deletion has to reach the log and every snapshot

A document is a log of everything anyone ever typed into it, including text they deleted seconds later. A delete that only removes the current state leaves all of it intact in document_ops and inside every snapshot — which is fine for a trash can and a failure for an erasure request under GDPR or similar regimes.

Hence §7's explicit state machine: active → trashed → purging → purged. Purge is an asynchronous job with a completion SLA that deletes the document's log partition, deletes every snapshot row, and removes derived copies from the search index and export cache. Two things make it tractable: partitioning by doc_id means a purge is a partition drop rather than a scan, and the tiered retention of §9 means there is far less to delete than 13 TB/day would suggest. Erasure of one user's contributions from a shared document is a much harder problem and is usually scoped out deliberately — the operations are interleaved with other people's and removing them changes the document.

Interview probe, L6/L7: "A user asks you to delete everything they typed in a shared document. Can you?" The valuable answer distinguishes deleting a document they own from surgically removing their operations from someone else's document, and explains why the second is not the same request.

4. A client that lies, and one that is merely broken

The protocol in §5b is generated by client code the server does not control. Three validations are non-negotiable, and all three are cheap:

Interview probe, L5: "What stops a modified client from sending an operation at position ten million?" Bounds-checking after transform, rejection rather than clamping, and the observation that the cost of getting this wrong is a corrupted document rather than an error page.

This question separates levels unusually cleanly, because the depth ladder is built into the problem: a working editor, then a justified convergence mechanism, then keeping exactly one authority alive through failure, then evolving the transform semantics without corrupting anything.

Classic interview probes

Every architectural decision in this article is downstream of about twenty numbers. Not one of them needs to be precise. What earns credit is knowing which number settles which argument: the reason the server cannot sit on the render path, the reason a document cannot be sharded, the reason the offline promise and the compaction schedule are the same number written twice.

Each row below is one number and the argument it closes, in that order. “One frame at 60 Hz is 16 ms, a round trip is four frames, so the server is not on the render path” is a complete argument in one breath; the same number without the second clause is recall.

Latency: the numbers that set the propagation budget

Throughput ceilings: the numbers that decide how many boxes

These answer “how much fits on one machine?” — which in this system is two separate questions, because the fleet and the busiest document are sized by different things and only one of them can be solved with money.

Volume and cadence: the numbers that decide what gets kept