Operational Transforms vs CRDTs

Google Docs can merge a keystroke from Tokyo and a deletion from São Paulo, both typed in the same millisecond against the same sentence, and produce the correct result. Figma does the same, but without a central server—each client merges changes offline, reconnects, and converges to the same canvas as every other client without asking anyone’s permission. Both systems solved the same mechanical problem: what do you do when two operations arrive out of order and the second one’s index is no longer valid? The answer separates wire-efficient collaborative platforms from peer-to-peer ones.

Two concurrent edits on the same string expose why position indices fail: the second operation was born against an old state and cannot be blindly replayed.

The Naive Approach: Why Position Indices Fail

Start with a string: HAT. Two users are editing it at the same time.

• User A opens HAT and inserts X at position 1, intending HXAT.
• User B opens the same HAT and deletes position 2 (the T), intending HA.

Both operations are created against the same state. If User A’s edit reaches the server first, the canonical state becomes HXAT. Now User B’s operation arrives—still carrying its original payload: “delete position 2.”

If you naively apply it: position 2 in HXAT is A. You delete A, producing HXT. But User B wanted to delete T, not A. The result is wrong.

This is the index-shift problem. Operations carry positions that are only valid against the state their author saw. Every other replica that did not see the same state interprets that position differently. Replaying operations in receive order without adjustment produces corruption.

Three strategies exist to escape this trap. One has won in practice; the other is theoretically cleaner but heavier. Let’s explore both.

Two Solutions: Transformation vs. Identity

Operational Transforms (OT): Adjust the Index

OT’s insight: don’t replay the operation as-is. Transform it against all operations it did not see, adjusting its index so it targets the right element in the new state.

In the HAT example:

• User A’s op: insert X at position 1.
• User B’s op: delete position 2.
• User B’s op is transformed: since A inserted 1 character before position 2, B’s position must shift up by 1.
• B becomes: delete position 3.
• Apply to HXAT: delete T at position 3 → HXA. Correct.

The catch: OT’s transformation functions are notoriously subtle. You must define transform(opA, opB) for every pair of operation types—insert vs. insert, insert vs. delete, delete vs. delete. Getting commutativity wrong (so that transform(A, B) + transform(B, A) do not converge) means clients diverge silently. Google spent years on their implementation; even then, bugs slipped through.

OT also requires a central server. The server is the authority: it receives all operations, orders them with a logical clock or total sequence number, transforms each incoming operation against the previous history, and broadcasts the canonical result. Clients cannot merge peer-to-peer because without a referee, you cannot agree on which transformations to apply.

CRDTs: Assign Immutable Identities

CRDTs flip the problem. Instead of relying on positions that shift, assign each element a unique, stable identifier when it is created. Operations reference IDs, not indices. Merging becomes simple: apply all operations in the order they were given, and they converge because the IDs are immutable.

Same HAT example with CRDTs:

• Initial characters: H (ID: h₁), A (ID: a₁), T (ID: t₁).
• User A’s op: insert X (ID: x₁) before a₁.
• User B’s op: mark t₁ as deleted (tombstone).
• Merge: apply both ops by ID → characters in order h₁, x₁, a₁, t₁-deleted → HXA. Correct, no transformation needed.

The elegance: if User A and User B receive each other’s operations in different orders, they still converge. Both apply insert-X-before-A and mark-T-deleted. The IDs define the canonical order. Merging is commutative — the order of operations does not matter.

The cost: every character is now a record {value, id}, not just a character. Deletions are tombstones, not erasures, because you cannot remove data until you know every replica has seen the deletion (otherwise, if a straggling replica resurrects the deleted character after a merge, you diverge). A 1 MB document becomes 10+ MB in memory.

How Each Approach Works: Mechanism

OT’s Architecture

1. Client A issues an operation locally and broadcasts it to the server: insert("X", position=1).
2. Server receives A’s op, assigns it version number V1, applies it: state is now HXAT.
3. Client B, still editing against the old state, issues: delete(position=2) — and sends it to the server.
4. Server receives B’s op. B was created against V0 (original HAT), but the server is now at V1. Transform B’s op against V1: delete(position=2) → delete(position=3) (because A inserted 1 char before position 2).
5. Server applies the transformed op: HXAT → HXA. State is now V2.
6. Both clients download the canonical history (or receive diffs) and rebuild to V2: HXA.

The server is essential: without it, clients cannot agree on the transformation order.

CRDT’s Architecture

1. Client A (offline or online) creates an operation with its own node ID and logical clock: insert(value="X", id=(nodeA, clock=1), before=a₁).
2. Client A applies it locally → HXA (on client A’s replica).
3. Client B (offline or in a different session) creates: delete(id=t₁).
4. Client B applies it locally → HA (on client B’s replica).
5. Merge: when A and B sync (via server, P2P, or sneakernet), they exchange operations. Client A receives B’s delete(t₁) and applies it by ID: the deleted character vanishes, leaving HXA. Client B receives A’s insert(id=(nodeA,1), before=a₁) and applies it by ID: inserts X before a₁, producing HXA. Both converge.

No server, no transformation, no total order needed. Offline-first systems thrive here.

Both approaches converge to the same result HXA, but OT transforms indices while CRDT relies on immutable character identities.

Trade-offs: When to Choose Each

Choose OT if:

• You control a central server and can tolerate clients being online-first.
• Wire efficiency matters—OT operations are compact (delta + position), while CRDT tombstones bloat state.
• Your domain has simple operation types (insert/delete at a position). Complex merges (e.g., reordering a tree) are hard to transform correctly.
• You are Google Docs and you have already debugged the transformation functions over a decade.

Choose CRDT if:

• You need offline-first or peer-to-peer collaboration (Figma, local-first apps).
• You can afford the metadata overhead (character IDs, tombstones).
• You want proven, well-tested algorithms (like Yjs, Automerge) rather than custom transformation logic.
• Simplicity and correctness matter more than bandwidth. CRDTs converge by construction; OT correctness depends on subtle, easy-to-break transformation functions.

Neither is universally better. OT dominated the 2000s and 2010s because servers were normal and bandwidth was scarce. CRDTs are rising because offline-first and decentralized systems are becoming mainstream. Google Docs and Microsoft Word still rely on OT. Figma, Linear, and a new generation of local-first tools use CRDTs (via libraries like Yjs or Automerge).

The Real Lesson

The index-shift problem is unavoidable in concurrent editing. You must either (1) transform indices to account for unseen operations, which requires a referee to agree on order, or (2) abandon indices and use immutable IDs, which trades bandwidth for simplicity. There is no free lunch—only trade-offs, and the choice depends on your infrastructure and values.

Most engineers encounter this problem when they try to build multiplayer features into their app. Now you know the two canonical solutions and why each one exists. The next time you edit a Google Doc with a colleague or collaborate on a Figma design, the convergence you see is one of these two mechanisms working quietly in the background.