Operational transformation

Why it matters

Two people type into the same document at the same time. Alice inserts a word at position 5; Bob deletes the character at position 2. If each client applies the other's operation literally, Alice's insert lands one position off on Bob's screen and the documents diverge forever. Operational transformation is the technique that adjusts operations for what happened concurrently, and it has run Google Docs, Office online and many editors for two decades. It is the classic contrast to CRDTs and a favourite way to test whether you understand concurrent editing.

The idea

Each edit is an operation with a position: insert(pos, text) or delete(pos, length). When a client receives an operation that was generated concurrently with operations it has already applied, it transforms the incoming operation against each of them so that its position accounts for their effect, then applies it. The transform function T takes two concurrent operations and returns a version of the first adjusted for the second.

The two properties

Convergence: all clients that have applied the same set of operations, in any order, end up with the same document. Intention preservation: each operation's effect on the final document matches what the user meant (Alice's X should appear between D and E regardless of Bob's deletion). Transform functions are defined for every pair of operation types, insert against insert, insert against delete and so on, and getting them right for all cases is notoriously subtle; the research literature is full of published transforms later shown to be wrong in three-way concurrent scenarios.

The central server

The practical fix for that subtlety is architecture: route all operations through a server that imposes a total order. Each client sends its operations to the server and holds them in a pending buffer; the server applies them in arrival order, transforming each against operations it has accepted since the client's last known state, and broadcasts the result. Clients transform incoming server operations against their pending local ones. With a single ordering point, only pairwise transforms are needed and the hard multi-way cases disappear. This is the Jupiter model that Google Docs and most production OT systems use.

	Operational transformation	CRDT sequences
Coordination	Central server for ordering (in practice)	None; peer-to-peer and offline work natively
Operation shape	Position-based; transformed against concurrent ops	Identifier-based; each item has a unique position id
Metadata	Small: just the operation	Larger: position ids and tombstones per character
Correctness burden	Transform functions must be right for all pairs	Merge is correct by construction; complexity is in id schemes and garbage collection
Offline and long disconnects	Harder; long pending buffers and server state	Natural; merge whenever reconnected
Rich text and structure	Mature (Google Docs, Quill's Delta)	Maturing (Yjs, Automerge handle rich text and JSON)
Used by	Google Docs, Office online, Etherpad, Quill-based editors	Figma multiplayer, Apple Notes, many offline-first apps

Practical details

Operations are usually expressed as compact deltas (retain n, insert text, delete n) that compose and transform cleanly. Clients keep a revision number and the server rejects or transforms operations based on the revision they were generated against. Undo must transform the inverse operation against everything since. Cursors and selections are transformed too, which is why a collaborator's cursor stays on the right character while you type above it. Presence, comments and formatting are separate streams layered on the same ordering.

Choosing between OT and CRDTs

With a reliable server and clients that are mostly online, OT is compact, mature and well understood. For peer-to-peer, offline-first or very large documents where a central ordering point is unwanted, CRDTs remove the coordination and the transform correctness problem at the cost of metadata. Several modern editors have migrated to CRDTs; several of the largest still run OT. Both achieve the same user-visible goal: everyone converges and nobody's edit is lost.