How Cambridge Researchers Built the Invisible Infrastructure Behind Google Docs and Figma

There is a moment every software engineer remembers: the first time they opened a shared document and watched someone else's cursor move across the screen in real time. No dialog box asking who wins. No lost keystrokes. Just two people, typing together, and the document somehow knowing how to hold all of it.

That seamlessness has a name, even if most users never hear it. It is called a CRDT a conflict-free replicated data type. And the story of how it came to exist is a story about a handful of researchers who saw a problem everyone else had given up on, and then quietly spent years building the mathematical machinery to solve it.

The Problem Nobody Wanted to Touch

Distributed systems have a dirty secret. When multiple computers hold copies of the same data, and those computers stop talking to each other a network partition, a dropped Wi-Fi signal, a server that goes offline something has to give. The CAP theorem, formalized in the early 2000s, laid out the trade-off starkly: a distributed system cannot simultaneously be consistent, available, and partition-tolerant. You have to choose two.

For decades, the conventional answer was consistency. Keep one authoritative copy of the data. Route all writes through a central server. Everyone else reads from that single source of truth. This worked, more or less, as long as the network cooperated. But the moment you wanted offline editing, peer-to-peer collaboration, or mobile workflows that worked without a signal, the model broke down.

The alternative was optimistic replication: let every replica accept writes independently, then merge the results later. The problem was that merges were messy. If two people changed the same paragraph, who wins? If someone deleted a line while someone else was editing it, what happens? In the general case, these conflicts could not be resolved automatically. You either threw away one person's work or you left the data in an inconsistent state.

"The conflict resolution design of Eventual Consistency is difficult, few articles give design guidance suggestions, and randomly designed solutions are error-prone," according to Zxch3n's introduction to CRDTs, summarizing the motivation behind the CRDT concept. That difficulty drove researchers toward a radical question: what if the data structure itself could not produce conflicts?

The 2011 Definition That Changed Everything

The formal definition of CRDT first appears in Marc Shapiro's 2011 paper Conflict-free replicated data types, though earlier groundwork existed. According to Zxch3n's technical overview, Shapiro had actually written a paper titled Designing a commutative replicated data type in 2007, and in 2011 reworded "commutative" into "conflict-free," expanding the definition to include state-based CRDTs. The 2011 paper, co-authored with Nuno Preguiça, Carlos Baquero, and Marek Zawirski, is what the field considers the founding document.

The core insight was elegant. If a data structure is designed so that any two updates, applied in any order, produce the same result, then conflicts are mathematically impossible. This requires the operations to be commutative, associative, and idempotent properties that, taken together, guarantee that replicas will converge to identical state as long as they receive the same updates, regardless of delivery order or timing.

According to the Wikipedia entry on CRDTs, the development was initially motivated by collaborative text editing and mobile computing. The researchers wanted an approach where all concurrent updates could be allowed to go through, with inconsistencies created and then merged or resolved later, without a central arbiter deciding who wins.

Two Roads Into the Same Destination

Paulo Sérgio Almeida's 2023 paper Approaches to Conflict-free Replicated Data Types, published on arXiv, provides what many consider the definitive modern tutorial on the two main CRDT approaches. The paper offers "a historical tour of the evolution from sequential data types to CRDTs," then presents in detail the two primary families: operation-based and state-based, including their variations.

Operation-based CRDTs describe updates as operations "add this item," "increment this counter" and propagate those operations to all replicas. Each replica applies operations as it receives them. Because the operations are designed to commute, the final state is the same regardless of order.

State-based CRDTs take a different path. Each replica maintains its full state and periodically compares that state with other replicas. When states differ, they merge by applying a join operation that combines the two states into one. The join operation is designed to be commutative, associative, and idempotent, so convergence is guaranteed.

Almeida's paper clarifies misconceptions that frequently occur in the literature and presents novel insights gained from considerable experience designing both specific CRDTs and approaches to CRDTs. For practitioners evaluating which approach fits their architecture, the distinction matters: operation-based CRDTs tend to be more efficient when updates are frequent and network latency is low; state-based CRDTs are often simpler to implement and work well when replicas need to synchronize infrequently.

Martin Kleppmann and the Cambridge Contribution

While Shapiro and colleagues established the theoretical foundation, much of the subsequent development happened across multiple institutions. One of the most active centers was the University of Cambridge, where Martin Kleppmann emerged as a leading figure in CRDT research and implementation.

Kleppmann's work has spanned both theoretical advances and practical implementations. According to the comprehensive CRDT papers list maintained at CRDT.tech, he co-authored two papers presented at the 2024 Workshop on Principles and Practice of Consistency for Distributed Data (PaPoC): one on undo and redo support for replicated registers with Leo Stewen, and another with Liangrun Da on extending JSON CRDTs with move operations.

The undo/redo work addresses a subtle but important problem in collaborative editing: how do you support "undo my last change" when multiple people are making changes simultaneously? In a single-user system, undo is straightforward you reverse the last operation. In a collaborative CRDT, reversing one user's operation might conflict with subsequent changes made by others. Kleppmann and Stewen's paper explores how to design CRDTs that support meaningful undo semantics in a multi-user environment.

The JSON CRDT extension work tackles another practical gap. Most CRDT libraries support primitive types counters, sets, registers but real applications need structured data. JSON CRDTs allow applications to represent complex nested data structures as CRDTs, enabling collaborative editing of rich document formats without losing the convergence guarantees.

From Theory to Production: How Figma, Notion, and League of Legends Adopted CRDTs

Theory is one thing. Production deployment at scale is another. And this is where the CRDT story becomes not just academically interesting but practically relevant to anyone building mobile workflows or automation tools.

According to Zylos Research's 2026 analysis of CRDTs and real-time collaboration, the debate between CRDTs and Operational Transformation (OT) the older approach used by Google Docs has largely settled into a consensus: the right choice depends on your architecture. Google Docs uses OT for centralized real-time editing with sub-millisecond latency, leveraging its reliable centralized servers and strong consistency requirements. Figma switched from OT to CRDTs in 2019 specifically for offline-first capabilities and decentralized collaboration.

The distinction matters for ReadySyncGo readers evaluating synchronization approaches. OT transforms index positions to ensure convergence but requires a central server for coordination. CRDTs use mathematical models without index transformations and do not require a central source of truth. They can work offline and sync when reconnected exactly the behavior mobile workflow users expect when they lose signal in a tunnel or work on a plane.

Notion uses a hybrid approach: CRDTs for structure, OT for text within blocks, enabling fine-grained undo. Linear uses CRDTs for metadata like status, assignee, and labels, while using OT for issue descriptions. League of Legends runs its chat system on CRDTs backed by the Riak database, supporting 7.5 million concurrent users handling 11,000 messages per second.

These are not toy examples. They represent production systems where CRDTs have been battle-tested at internet scale.

The Performance Revolution: Automerge and Yjs Cross the Finish Line

Early CRDT implementations carried a reputation for poor performance. The mathematical elegance came with computational overhead merging operations required more processing than simply writing to a central database. For years, this limited CRDT adoption to applications where the offline-first benefits clearly outweighed the performance cost.

That calculus changed dramatically. According to Zylos Research, modern implementations have overcome historical performance challenges. Automerge 2.0 achieved a 600-millisecond processing time for 260,000 keystrokes, down from an earlier version that took 2 seconds per character. Yjs handles between 26,000 and 156,000 operations per second depending on workload.

These numbers represent a qualitative shift. A text editor that once felt sluggish now performs comparably to non-CRDT alternatives, while offering the offline-first, peer-to-peer, end-to-end encrypted collaboration that traditional approaches cannot provide.

The Tombstone Problem and What Production Teams Do About It

No technology is without trade-offs, and CRDTs have one that practitioners should understand: the tombstone problem. When an element is deleted in a CRDT, it cannot simply be removed. The deletion must be recorded as an operation so that other replicas know not to resurrect the element when they receive later updates. These deletion markers tombstones persist as metadata.

In documents with heavy editing histories, tombstones can accumulate. According to Zylos Research, files with 10 million tombstones can balloon to gigabytes. Production systems mitigate this through aggressive compaction, time-to-live policies that expire old tombstones, and hybrid architectures that periodically consolidate state.

For ReadySyncGo readers evaluating CRDT-based tools, this is worth knowing. If you are building an application with frequent deletions say, a collaborative task manager where completed items are routinely deleted the storage overhead of tombstones may require active management. Most mature CRDT libraries handle this transparently, but it is not a problem that disappears on its own.

Why This Matters for ReadySyncGo Readers

ReadySyncGo covers data sync, mobile workflows, and automation tools. If you are evaluating how to build collaboration into your product, or choosing which synchronization approach to adopt, understanding CRDTs is increasingly non-optional.

The alternative Operational Transformation requires central coordination. That works fine when your users are always online and always connected to your servers. But mobile workflows are different. Users expect their tools to work on the subway, in airplane mode, in rural areas with spotty coverage. They expect that when they reconnect, their changes merge automatically with whatever their colleagues did in the meantime.

CRDTs are the mathematical foundation that makes that experience possible. They are why Figma users can edit designs offline and sync when they reconnect. They are why League of Legends players can chat reliably even during server hiccups. They are why collaborative text editors can show multiple cursors without losing anyone's work.

For practitioners, the question is no longer whether CRDTs work. The question is which CRDT approach fits your architecture, which library to build on, and how to handle the tombstone problem in your specific use case. The research community has answered the first question. The implementation community has answered the second. The third is an exercise for your specific product team.

Where the Research Goes Next

The CRDT research community continues to advance on multiple fronts. Almeida's 2023 tutorial paper identifies and clarifies misconceptions that frequently occur, suggesting that even experienced practitioners sometimes misunderstand the guarantees CRDTs provide and more importantly, what they do not provide.

Security is an emerging focus. Florian Jacob and Hannes Hartenstein's 2024 PaPoC paper explores logical clocks and monotonicity for Byzantine-tolerant replicated data types, addressing scenarios where some replicas may behave arbitrarily badly either due to bugs or malicious behavior. This matters for applications where trust boundaries exist between participants.

Verification is another active area. Julian Haas and colleagues' 2024 paper in ACM Transactions on Programming Languages and Systems presents LoRe, a programming model for verifiably safe local-first software. The goal is to make it possible to prove that a CRDT implementation meets its correctness guarantees, rather than relying solely on testing.

For practitioners, these directions suggest a maturing field. CRDTs are moving from "interesting research" to "production infrastructure," and with that maturation comes the expectation of stronger correctness guarantees, better security properties, and clearer guidance on when and how to use them.

Timeline: Key Milestones in CRDT Development

Where to Read Further

The CRDT research landscape is rich, and these primary sources offer different entry points depending on your background and goals.

For a comprehensive technical tutorial that clarifies misconceptions and presents both operation-based and state-based approaches in detail, start with Paulo Sérgio Almeida's Approaches to Conflict-free Replicated Data Types on arXiv, published in October 2023. It is described as a tutorial for prospective CRDT researchers and designers.

For a practitioner-focused overview of how CRDTs compare to Operational Transformation and which production systems use each approach, Zylos Research's analysis of CRDTs and real-time collaboration provides concrete examples including Figma, Notion, Linear, and League of Legends.

For the foundational definition and conceptual background, the Wikipedia entry on CRDTs remains a useful starting point, documenting the 2011 formal definition and the initial motivation from collaborative text editing and mobile computing.

For those building collaborative applications and wanting to understand the design challenges, Matthew Weidner's CMU PhD blog post on designing data structures for collaborative apps walks through the practical decisions involved in choosing and composing CRDTs.

The CRDT Papers page at CRDT.tech maintains a comprehensive, reverse-chronological list of research publications, filterable by topic from introductions to security and Byzantine fault tolerance, making it the best starting point for tracking the research frontier.