OT or CRDT — and the Consistency Contradiction

In one line: the chapter treats OT and CRDT as interchangeable options that both deliver the same guarantee. They are not interchangeable, they do not deliver the same guarantee, and the difference determines whether the architecture needs a coordinator at all.

The contradiction

Three statements, and they cannot all be true

Set the design's own sentences side by side:

Lesson 4 (concurrency): "CRDTs guarantee eventual consistency."

Lesson 4 (concurrency): "CRDTs are gaining popularity because they support serverless and peer-to-peer collaboration models."

Lesson 5 (evaluation): "We ensure strong consistency for conflict resolution using OTs or CRDTs."

Lesson 5 (evaluation): "The system uses strong consistency for conflict resolution, and a logically centralized server determines the final order of operations for all clients."

The first and third are directly incompatible: you cannot get strong consistency from a mechanism the same chapter defines as eventually consistent.

The second and fourth are incompatible in a different way. CRDTs are praised for being serverless; the design's stated mechanism is a logically centralized server. If you have a centralized ordering authority, you are not running the CRDT architecture — you are running OT's architecture and calling it a choice of algorithm.

Which claim survives? The fourth one, because it describes an actual mechanism rather than asserting a property. A logically centralized server fixing a total order does give strong consistency, and that is OT. So:

The design is:            OT with a centralized ordering queue
The consistency claim:    valid, and comes from the QUEUE, not from "OT or CRDT"
The CRDT mention:         an alternative that would REMOVE the queue,
                          and with it the strong-consistency guarantee

Consistency is a property of the coordination architecture, not of the conflict-resolution algorithm. Swapping OT for CRDTs is not a drop-in substitution — it changes what the system guarantees and deletes a component.

What each combination actually gives you

The third row is what real CRDT systems actually do, and the design misses it

The chapter presents a binary — centralized OT or serverless CRDT — and production systems mostly sit in between.

Figma, Yjs-based editors, and Automerge deployments almost all run a server. But the server's role is different in kind:

OT server:   DECIDES the order. Correctness depends on it.
             If it is unavailable, clients cannot safely converge.

CRDT server: RELAYS operations and PERSISTS them. Correctness does not depend on it.
             If it is unavailable, clients that can reach each other still converge,
             and clients that cannot keep editing locally and merge later.

That is a large availability difference from a component that looks identical on an architecture diagram.

Ask what happens to correctness when the coordinator is unavailable — that is what distinguishes a coordinator from a relay. The design's own admission is telling here: "clients may experience brief service unavailability while the component is restarted." A CRDT design would not have that sentence.

Why the design chose strong consistency

Amazon's Dynamo system shows that using eventual consistency for conflict resolution can produce multiple document versions that must later be reconciled, either automatically or manually. With automatic reconciliation, the document state may change unexpectedly, which can disrupt the collaborative editing experience. Manual conflict resolution is time-consuming and undesirable.

The Dynamo argument is right about shopping carts and wrong about CRDTs

The reasoning is sound as far as it goes, and it misidentifies its own target.

Dynamo's problem is real. Dynamo used vector clocks to detect conflicts and then handed sibling versions back to the application to reconcile. For a shopping cart the application merges by union — a famously imperfect answer, which is why deleted items reappear. For a document, showing a user two versions and asking which to keep is unusable.

But that is not what a CRDT does. The distinction is precisely the "conflict-free" in the name:

Dynamo:  DETECTS conflicts, hands siblings to the application to merge.
         -> multiple versions, manual or ad-hoc reconciliation

CRDT:    the merge function is DEFINED IN THE DATA TYPE and is
         commutative, associative, and idempotent.
         -> exactly one result, computed automatically, identical on every replica
         -> NO siblings, EVER

So the argument against eventual consistency here is an argument against Dynamo-style eventual consistency, not against CRDTs. A CRDT never produces the multiple versions the paragraph objects to.

There is still a legitimate concern hiding underneath, and it is the "state may change unexpectedly" clause: under eventual consistency, a user can see their own text momentarily, then see it move as a remote operation arrives. That is a genuine UX cost. But it is a convergence-latency complaint, not a multiple-versions complaint, and it is the honest version of the argument.

"Eventual consistency" is not one thing — the useful question is whether the merge is defined by the data type or left to the application. That distinction separates CRDTs from every eventually-consistent store in the module.

The design's own note describes exactly the failure it claims to have prevented

Note: "Because different users can be collaborating on the same document, one user's change may fork a new copy than the other user's version of the same document. Such changes can have a cascading effect, eventually leading to undesired behavior."

This note sits directly beneath the strong-consistency claim, and it describes document forking — the multiple-versions problem the Dynamo paragraph rejected eventual consistency to avoid.

If the system truly has strong consistency via a centralized total order, forking cannot happen: every operation is ordered against every other, and every client applies the same sequence. There is exactly one document.

So one of the two is inaccurate. The most charitable reading is that the note is warning about the asynchronous replication the latency section introduces — "for highly popular documents, asynchronous replication improves performance, though it makes strong consistency harder to guarantee" — which the design does state plainly.

That reading makes the note correct and the compliance claim overstated: the design has strong consistency within the ordering path and eventual consistency across asynchronously-replicated regions. Which is a perfectly reasonable design; it is just not "strong consistency" without qualification.

When a design claims a global guarantee, check whether every replication path preserves it — a single asynchronous hop downgrades the whole claim.

How to choose, in an interview

The decision criteria, in order of how much they actually decide

Neither technique is better. The choice falls out of four questions, roughly in this order of weight.

1. Do you have a reliable central server? If yes, OT is viable and buys you plain-text documents. If your product must work peer-to-peer or offline-first, CRDTs are the only option — there is nothing for OT to transform against.

2. How large are the documents, and how many are there? CRDT metadata multiplies storage. At Google Docs scale that is decisive, and it is very likely why Docs runs OT. At Figma's scale — fewer, richer documents — it is affordable.

3. How variable is the network? Order dependence is OT's real operational weakness. Globally distributed collaborators on poor links argue for CRDTs, as the design's own Q&A concedes.

4. How complex is your operation set? Plain text has three operations; a rich editor has dozens, and OT's rules grow quadratically. A large operation vocabulary argues strongly for CRDTs, because their complexity is per-character rather than per-operation-pair.

The honest summary — and a good thing to say out loud:

"OT puts the complexity in the algorithm; CRDTs put it in the data. Docs chose OT because at their scale document size dominates, and they had the engineering budget to get the transformations right — the Wave team spent two years on it. If I were building something today with fewer, larger documents, or that had to work offline, I would take CRDTs and accept the metadata."

The one thing not to say

Do not say the design "uses OT or CRDTs for strong consistency." It is the design's phrasing and it is the tell that the trade-off was not understood.

The strong-consistency guarantee comes from the centralized ordering queue, not from the conflict-resolution algorithm. Remove the queue and you have an eventually-consistent system regardless of which algorithm you kept; keep the queue and you have strong consistency regardless of which one you kept.

Name the mechanism that produces the guarantee, not the component nearest to it. That is the same discipline the evaluation lessons of every chapter in this module have been testing.

What each technique demands of the surrounding architecture

Worth seeing explicitly, because the algorithm choice reaches beyond the algorithm:

The queue is replicated because it is a single point of failure for correctness; the relay is not. And the CRDT history is larger because every operation carries its identity — the storage cost from Lesson 6 shows up again in the log.

Readers do not need any of this

The conflict machinery exists for people writing to the document. A read-only viewer needs none of it — no persistent connection, no transformation, no server affinity. Serving them a materialized snapshot through ordinary caching scales to millions without touching the editing path.

That split matters because the two populations differ by orders of magnitude. Making every viewer a participant in the collaboration protocol would impose the hardest part of the system on the easiest case, which is exactly the trade to avoid.

Next: the evaluation.