Evaluation

In one line: the scalability argument here is the cleanest in the module — and the availability section contradicts itself in the space of two paragraphs.

Consistency

Covered in full in Lesson 7. The short version: the guarantee comes from the centralized ordering queue, not from "OT or CRDTs," and it holds within the ordering path but not across the asynchronously-replicated regions the latency section introduces.

Updated states are replicated using peer-to-peer protocols such as Gossip. This approach improves both consistency and availability.

Gossip is the right tool and it is not a strong-consistency mechanism

Gossip is an excellent fit for propagating state within a data center — it is robust to node failure, needs no membership coordinator, and scales logarithmically. The module has met it before, in the same role.

But gossip is epidemic and probabilistic: state spreads with high probability in O(log n) rounds, with no bound on when any particular node receives it. That is eventual propagation by construction.

So the sentence "improves both consistency and availability" needs qualifying. Gossip improves durability and availability of the resolved state, and it makes replicas converge — eventually. The strong-consistency guarantee comes from the ordering decision that happens before gossip runs, not from the replication that carries it.

Distinguish the component that decides from the component that distributes — only the first can give you a consistency guarantee. This is the same distinction as Lesson 3's queue-as-serializer versus queue-as-buffer.

Latency

Each client maintains a local replica... updates propagate via WebSockets, keeping perceived latency low. Most edits consist of small text payloads.

Documents have a limited number of active editors. Readers load the document once and can be served from a single data center. For writers, selecting an optimal zone close to collaborators helps minimize latency. For highly popular documents, asynchronous replication improves performance, though it makes strong consistency harder to guarantee.

The local replica is why the system feels instant, and it is worth naming explicitly

This is the most important latency decision and the design states it in passing.

Every keystroke renders locally, immediately, with no round trip. The operation is then sent for ordering, and any correction arrives afterwards. So the user's perceived latency is zero, regardless of geography — a collaborator in Sydney and one in London both see their own typing instantly.

That is why the whole conflict-resolution apparatus is necessary. If the client waited for the server to confirm each character, there would be no divergence and no conflicts — and typing would be unusable at 200 ms of RTT.

Optimistic local application  -> instant UX, divergence, conflicts to resolve
Server-confirmed application  -> no conflicts, unusable typing latency

Optimistic local execution buys perceived latency and pays for it in consistency machinery. Every collaborative system in this module that felt instant made the same trade.

'Selecting an optimal zone close to collaborators' is data placement, and it is well judged here

This works better for documents than for almost any other data type in the module, for a reason worth naming.

The access set is tiny and stable. A document has at most twenty editors, they are usually in the same organization, and the set changes rarely. So "put the document where its collaborators are" is a computable, stable answer.

Contrast with the module's other systems: a tweet's readers are unbounded and global, an Instagram post's audience is unpredictable, a Uber ride's participants change every trip. None of them has a small stable access set, so none of them can place data by locality of writers.

Twitter:      readers unbounded  -> replicate everywhere, cache aggressively
Google Docs:  writers <= 20      -> PLACE the document near them

Data placement by access locality only works when the access set is small, stable, and known — and this is one of the few systems where all three hold.

The residual case is the one the design flags: a document read by millions (a public form, a shared spec), where asynchronous replication is added and strong consistency degrades. That is the correct call — the read-heavy case and the write-heavy case want different replication, and only the write path needs the ordering guarantee.

Availability

Availability is achieved through replication and continuous monitoring. Core components such as operation queues and data stores handle replication internally. Running multiple WebSocket servers improves fault tolerance. Caching layers and CDNs further enhance availability.

Disaster recovery is not addressed in the current design.

Disaster recovery is disclaimed in the prose and claimed in the table

Two statements, one lesson apart:

They cannot both be right, and the prose is almost certainly the accurate one — nothing anywhere in the chapter describes a backup strategy, an RPO, an RTO, or a cross-zone failover procedure.

This is the recurring pattern in this module's compliance tables: the table lists techniques the design should use rather than techniques the design contains. Yelp's table did it, Uber's did it, and here it happens while the prose is explicitly disclaiming the item three lines above.

The honest version would be a compliance table with a third column:

Read a compliance table as a checklist of intent, not a description of the system, and in an interview say which items are built and which are future work. Claiming an unbuilt property is the single easiest thing for an interviewer to falsify.

The ordering queue is a correctness SPOF, and the design half-admits it

"A replicated operations queue ensures that if the ordering service fails, it can restart on another server and continue processing from the previous state. Clients may experience brief service unavailability while the component is restarted."

This is more honest than most availability sections in the module — it names a real gap rather than asserting five nines.

But notice what it concedes. Editing stops during the restart. Not degrades — stops, because there is no one to order operations, and applying them unordered would diverge the replicas.

That is the availability price of strong consistency, and it is exactly the trade CAP describes: a partitioned or failed coordinator forces a choice, and this design chooses consistency over availability.

OT design:   coordinator down -> editing PAUSES (consistency preserved)
CRDT design: no coordinator   -> editing CONTINUES, converges on reconnect

That is the concrete, operational form of Lesson 7's argument. The question that separates the two architectures is what happens when the coordinator is unavailable, and this sentence answers it.

The mitigation the design has is right — replicate the queue and preserve its position so a restart resumes rather than replays or loses. The gap is that "brief" is unquantified, and for a system whose whole value proposition is real-time collaboration, the duration of that pause is the availability number that matters.

Scalability

The microservice architecture allows each component to scale independently. If operation queues become a bottleneck, multiple queues can be created, with each queue dedicated to a single document. All operations for a given document are routed to its assigned queue. The total number of queues scales with the number of active documents, enabling horizontal scalability.

This is the strongest paragraph in the chapter

It gives a mechanism, explains why it works, and the reasoning is exactly right.

The consistency requirement is per-document. Operations on different documents never need a shared order, so there is no reason for them to share a serialization point. Partitioning by document is therefore free of correctness cost — which is rare; most partitioning schemes trade away some guarantee.

The key distributes beautifully. Active documents number in the hundreds of millions, and the twenty-editor cap means no document can become a hot key. Compare with every other system in this module:

A partition key with a hard cap on per-key load is the ideal case, and it is usually a product decision rather than an engineering one. The twenty-editor limit is what makes this work, which is the same observation Lesson 2 made about fan-out.

The one thing to add: with hundreds of millions of active documents you do not run hundreds of millions of queue processes. You multiplex logical queues over a server pool via consistent hashing on document ID — the module's standard technique — with the document-to-server map in the coordination service.

What the evaluation omits

Three things a strong answer would add.

The history storage problem. History is a functional requirement; the estimation excludes it; at roughly fifty times the document size it is plausibly the larger half of storage. Snapshotting and operation compaction are the answers, and neither appears.

The edit-operation rate. The scalability section talks about queues per document without ever stating how many operations per second the system handles — the number that would actually size them. Lesson 2 works it out: keystrokes fanned out twentyfold.

Identifier growth in CRDTs. If CRDTs are offered as an option, the fractional-index growth problem belongs in the evaluation, because it is the thing that determines whether they are viable at all.

Keeping the operation log from growing forever

Storing every operation forever is correct and unaffordable. A document edited for years accumulates a log far larger than the document itself, and every load replays all of it.

Compaction collapses history into a snapshot. Materialize the document state at some version, write it as a new version, then flip a pointer in the document metadata to that version. Loading now means reading one snapshot plus the handful of operations since, rather than replaying years of edits.

The pointer flip is what makes it safe. Compaction builds the new version alongside the old one and switches atomically, so a reader is always looking at a complete consistent version and a failed compaction leaves the original untouched.

Run it at low priority, in a separate process. This is the detail worth volunteering: compaction is CPU-heavy and the document servers are latency-sensitive, so an unconstrained compaction pass shows up directly as tail latency on live editing. Isolating it — a separate process with lower scheduling priority — keeps a background chore from degrading the foreground experience.

Next: the interview walkthrough.