There’s a moment most of us have stopped noticing. You’re on a train, your connection drops for thirty seconds, and you keep typing in a shared document. The cursor keeps blinking. Your colleague’s edits appear in real time when the signal returns. Nothing breaks. No dialog box appears asking you to reload. No conflict resolution screen forces you to choose between two versions of your own work.
This wasn’t always the case. And the fact that it is now—across Figma, Notion, Linear, and a growing roster of collaborative tools—owes to a quiet mathematical bet that the industry spent the last decade making. It’s called a CRDT, or Conflict-free Replicated Data Type, and it’s replacing the older, more fragile approach that powered the first generation of real-time collaboration.
The OT Era—and Its Centralized Ceiling
When Google Docs launched browser-based collaborative editing in 2006, it ran on something called Operational Transformation, or OT. The idea was elegant in theory: every edit is an operation (insert character at position 5, delete character at position 12), and when concurrent operations arrive at the server, the server transforms them so they apply cleanly to every client’s local copy.
The problem is that OT requires a central authority to order and transform operations. The server is the arbiter of truth. That means every collaborative session depends on a live, low-latency connection to a server. It also means the transformation logic gets increasingly fragile as you add richer document types—nested tables, multiplayer whiteboards, programmatic content.
Google’s engineers spent years refining their OT implementation. It works, mostly, for documents that look like documents. But when you try to apply it to the kind of freeform, spatial, deeply structured data that modern creative tools handle, the seams start showing.
Enter the CRDT
CRDTs take a fundamentally different approach. Instead of transforming operations after the fact, they structure the data itself so that concurrent edits are mathematically guaranteed to converge. Two people can edit the same document on opposite sides of a dropped connection, and when their copies sync—whether through a server, a peer-to-peer relay, or a USB stick handed across a desk—their states will reconcile identically. No server arbitration required.
The trick is in the data model. A CRDT tracks not just the current state of a document but the causal history of every change. Each edit carries metadata about what came before it, so any two copies can merge in any order and arrive at the same result. It’s the difference between asking “what happened?” and asking “what is true?”
“The key insight is that if you can make the merge function commutative, associative, and idempotent, then the order in which updates arrive simply doesn’t matter. You get the same answer every time.” — Martin Kleppmann, researcher and creator of Automerge, one of the leading CRDT libraries.
This sounds abstract until you consider what it unlocks. If merge order doesn’t matter, you don’t need a central server. If you don’t need a central server, collaboration can happen peer to peer. Devices can sync directly. Documents can live offline indefinitely. A team in a bandwidth-starved office in Lagos can collaborate on the same design file as a team in Helsinki, with neither ever depending on a data center in Virginia.
The Quiet Migration
The shift is already well underway. Figma built its multiplayer architecture on a custom CRDT-like approach from the beginning, which is part of why it handled concurrent design edits more smoothly than any predecessor. Notion has been migrating its collaborative backend toward CRDTs. Linear uses them for issue tracking. The open-source editor Automerge, maintained by Kleppmann and collaborators, powers collaborative features in tools across the web. Yjs, another CRDT library created by Kevin Jahns, has become the de facto choice for building real-time collaboration into JavaScript applications.
The reasons for the migration are concrete:
- Offline-first capability — Because CRDTs don’t require a server to resolve conflicts, applications can function fully offline and sync later without risk of corruption.
- Simpler distributed architecture — Peer-to-peer sync becomes possible, reducing infrastructure costs and latency.
- Richer data models — CRDTs handle nested, structured, and spatial data more naturally than OT, which was designed primarily for flat text.
- Local-first software — The emerging philosophy that your data should live on your device first, with sync as a secondary concern, depends almost entirely on CRDTs.
The last point matters more than it might seem. The “local-first” movement, championed by researchers including Kleppmann, Ink & Switch, and others, represents a real philosophical alternative to the cloud-dependent model that has dominated software for fifteen years. It’s the idea that you should own your data, access it without a connection, and still get seamless collaboration—all of which CRDTs make technically feasible for the first time.
What It Costs
CRDTs aren’t free. They trade server complexity for client complexity. Every client must store enough metadata to merge correctly, which means larger document sizes and more sophisticated local storage. Memory usage and serialization costs are real concerns, especially for long-lived documents with deep edit histories. Garbage collection—deciding when old metadata can be safely discarded—is an active research problem.
There’s also the question of auth and permissions. OT’s centralized model made access control straightforward: the server decides who can edit what. CRDTs push the merge logic to the edges, which complicates the story for granular permissions, encryption, and governance. Projects like Automerge and Yjs are actively working through these challenges, but the tooling is still younger than the OT ecosystem.
And for pure text editing at massive scale—think thousands of simultaneous users on a single document—OT still has performance advantages in certain scenarios. The two approaches aren’t mutually exclusive, and some tools use hybrids.
The Invisible Infrastructure
What makes CRDTs interesting isn’t the mathematics. It’s what happens when the mathematics disappears into the product. The best infrastructure is invisible. You don’t think about TCP/IP when you load a webpage. You don’t think about CRDTs when your collaborator’s cursor moves across your shared board.
But the implications are worth noticing. For most of the collaborative-software era, “real-time” meant “dependent on a server.” That assumption shaped everything—pricing models, privacy architectures, what was even possible to build. CRDTs quietly dissolve that assumption. They make local-first software real. They make peer-to-peer collaboration real. They make a version of the internet where your tools work regardless of your connection, your cloud provider’s uptime, or your subscription status.
The revolution isn’t loud. It’s a data structure most people will never hear of, quietly rewiring the assumptions underneath everything they use to create together.
