Watch Operational Transformation resolve concurrent edits — two editors, one document, zero conflicts.
Both editors share a live document. Changes from either editor are merged in real time using a simplified OT algorithm — watch the log below to see how operations are transformed.
Choose a scenario to see how concurrent conflicting operations are detected and transformed.
OT transforms concurrent operations against each other so they compose correctly. If Alice inserts at position 3 while Bob deletes at position 5, and Bob's op arrives after Alice's, Bob's delete must be shifted to position 6 to account for Alice's insertion.
Conflict-free Replicated Data Types encode position into the data structure itself (e.g. Logoot, LSEQ, Yjs). Each character gets a globally unique fractional position — there's nothing to transform. CRDTs are simpler to distribute but use more memory.
CP1 (convergence): all replicas reach the same state. CP2 (intention preservation): the effect of each operation reflects the user's intent even after transformation. Achieving both simultaneously is the hard problem in OT.
Each client tracks a vector of operation counts per peer, e.g. [Alice:3, Bob:2]. This establishes a partial order of operations — detecting which were truly concurrent (neither happened-before the other) vs. sequential.
OT: requires a central server (or peer coordination) to order concurrent ops; mature (Google Docs uses it). CRDTs: fully peer-to-peer, works offline, but character IDs can bloat with many edits. Yjs (used by VS Code Live Share) is CRDT-based.
Deleted characters are marked as "tombstoned" rather than removed immediately. This preserves position indices for in-flight operations that reference those positions. Tombstones are garbage-collected once all peers have acknowledged the deletion.