“When two people type into the same document at the exact same millisecond, what prevents the text from turning into a jumble of gibberish?”
Seeing someone else’s cursor move in real time across Google Docs or Figma feels completely normal today. Under the hood, though, letting multiple people edit the same state without corrupting it is one of the trickiest problems in distributed systems.
For years, the default engineering answer was Operational Transformation (OT). More recently, attention has shifted toward Conflict-free Replicated Data Types (CRDTs). Here is how both work, and why the difference matters.
The Referee Model: Operational Transformation (OT) #
Imagine you and a colleague start with the word "CAT".
- At position 0, you insert
"A "to make"A CAT". - At the exact same moment, your colleague appends
"S"at position 3 to make"CATS".
If your friend simply applies your edit verbatim, their text becomes "A CATS". But if your machine blindly applies their edit (insert "S" at index 3), your result becomes "A CSAT"—because your local text already shifted two characters to the right.
OT solves this by transforming operations against each other so user intention is preserved despite index shifts.
The catch is that OT almost always needs a central server to act as an authoritative referee (the Jupiter architecture popularized by Google Docs). The server decides the official order of events.
That works reliably when everyone has a steady connection. But if you disconnect on a flight, rack up dozens of offline edits, and try to merge peer-to-peer later without a server around, resolving those divergent operation logs becomes an absolute nightmare.
How CRDTs Avoid the Referee #
Instead of having a central server serialize the sequence of edits, CRDTs adopt a more purely mathematical approach and rethink the structure of the data itself.
Rather than saying “insert character ‘x’ at index 4”, every piece of data gets a globally unique ID and a deterministic relative position between its neighbors. Updates are designed to commute:
- Merging edit A then B yields the exact same result as merging B then A.
- Packets can arrive late, out of order, or over completely different network routes.
- Once all devices receive the same set of updates, they are mathematically guaranteed to land on the identical state—no central referee, and no merge conflict dialogs.
Why This Matters: The Local-First Shift #
The difference isn’t just theoretical; it dictates how much autonomy users have over their software.
OT fits the traditional cloud model as the client is just a thin viewport, and the remote server owns the truth. If your connection drops, you’re locked out! If the service goes down, your data is unreachable!
CRDTs, on the other hand, are the backbone of the local-first software movement. Your data lives on your device first. You can work completely offline, edit across multiple devices, and sync peer-to-peer whenever you’re on the same network.
I put this directly into practice when building SHELF, a peer-to-peer distributed shopping list app. Implementing CRDTs using structures such as OR-Sets for item tracking and RGAs for list ordering allowed concurrent offline edits to converge deterministically over local networks without relying on any central server.
So if you’re building an app where connectivity is guaranteed and users never need offline access, OT gets the job done. But if you want software that works reliably anywhere and keeps data on the user’s local device, CRDTs are simply the better foundation.
For a deeper dive into this comparison and where I explored this topic, check out CRDTs vs. Operational Transformation.