How it works
Represent changes as operations rather than whole-document replacements: insert text at a position, delete a range, or apply formatting. Each submitted operation carries a unique operation ID and context, commonly the server revision on which it was based.
Concurrent operations can invalidate each other's positions. If two users start with "cat", one inserts "X" at position 0 while the other deletes "t" at position 2, applying the insertion first moves the intended deletion to position 3.
A transformation function rewrites an operation against another operation that was not in its original context. Insert-versus-insert needs a deterministic rule for equal positions; overlapping deletes may shrink a range or become a no-op. Correctness depends on the operation definitions and synchronization protocol, not just shifting offsets.
In a common centralized design, one logical owner sequences operations for each document. It transforms an incoming edit against accepted edits missing from that edit's context, assigns the next revision, and broadcasts the accepted operation. Clients apply their own edits immediately and use acknowledgments plus transformations against pending local edits to reconcile remote changes.
Persist accepted operations and periodically save snapshots for recovery. Reconnect uses a known revision and stable operation IDs to recover missing changes without duplicating edits; if required transformation history has expired, use an explicit resynchronization or merge flow. Cursor and selection positions also need adjustment as edits move text.
A worked example
Transforming a concurrent insertion and deletion
At revision 10, Alice and Bob both see "cat". Positions are zero-based character offsets. Alice inserts "X" at position 0 and immediately sees "Xcat". Bob deletes the character at position 2 and immediately sees "ca". The server accepts Alice's insertion as revision 11. Bob's deletion still references revision 10, so the server transforms its position from 2 to 3, deletes "t", and records revision 12. The accepted result is "Xca". Bob reconciles Alice's insertion with his pending deletion; Alice receives the transformed deletion. Both reach "Xca" without discarding either edit. Stable operation IDs prevent a retry from applying either edit twice.
Trade-offs to say out loud
- Immediate local feedback, complex reconciliation
- Users can type without waiting for a network round trip, but clients must correctly manage pending edits, acknowledgments, and incoming operations.
- Compact edits, difficult correctness
- Position-based operations can be small, but overlapping deletes, formatting, and undo require carefully defined transformations and extensive testing.
- Simple ordering boundary, per-document bottleneck
- A logical document owner simplifies sequencing, but one heavily edited document can overload that owner even when documents are distributed across many servers.
- History supports reconciliation, retention costs storage
- Transforming stale edits requires sufficient operation history or equivalent context, so snapshots alone do not solve long-offline reconciliation.
- Convergence is not semantic agreement
- A correct OT protocol can make replicas agree, but it cannot determine the authors' intended meaning when edits conflict.
- Synchronization is separate from durability
- Transforming an edit correctly does not make it durable, so acknowledgment semantics, replicated storage, deduplication, and owner failover still need explicit designs.
When to reach for it
- Multiple people must edit the same text simultaneously without locking the document or overwriting each other's changes.
- The interface must display local keystrokes immediately, even while remote changes are in flight.
- The design can use an authoritative per-document sequence and must reconcile edits based on older revisions.
- The interview asks how concurrent edits and cursor positions remain meaningful, rather than only how updates reach connected clients.
How to bring it up in the interview
- Start with a concrete insert-and-delete race and show why ordered delivery alone cannot fix positions calculated against an older document.
- Define the operation model, revision context, and deterministic conflict rules; expect probes about simultaneous inserts, overlapping deletes, and rich-text formatting.
- Walk through both sides of synchronization: server transformation against missing history and client reconciliation against unacknowledged local edits.
- State what a durable acknowledgment means and how operation IDs survive retries; expect follow-ups about reconnect, expired history, and fenced owner failover.
- Compare OT with CRDTs using the actual requirements: centralized coordination, offline duration, metadata costs, and implementation maturity, not a claim that either approach is always better.
Common mistakes
- Saying WebSockets or a server-ordered stream solves concurrent editing without transforming operations created against different document states.
- Explaining only insertion offsets and ignoring equal-position inserts, overlapping deletes, pending client edits, and undo.
- Claiming OT always preserves user intent or automatically guarantees convergence regardless of the transformation rules and protocol.
- Treating a snapshot as sufficient to transform arbitrarily old offline operations after the relevant history has been discarded.
- Confusing an edit displayed locally with an edit durably accepted by the server.
Where it comes up
Interview questions where operational transformation is part of a strong answer, and why.
Questions people ask
What is operational transformation in collaborative editing?
Operational transformation adjusts an edit to account for concurrent edits that changed the document since that edit was created. Combined with a correct synchronization protocol, it lets users edit local copies immediately and eventually reach the same document state.
What is the difference between operational transformation and CRDTs?
OT transforms operations using their context and concurrent edit history; many editor designs use a central server to sequence those operations. CRDTs define data structures and merge rules that make concurrent changes converge, often using stable element identifiers. Neither removes the need to design persistence, permissions, reconnect behavior, and editing semantics.
Does operational transformation support offline editing?
It can, provided the system retains enough history or equivalent context to reconcile offline operations. Long offline periods make history retention and pending-edit reconciliation harder. If the needed context is unavailable, the product needs an explicit merge or recovery path rather than silently applying stale positions to a fresh snapshot.