Building Collaborative Interfaces: Operational Transforms vs. CRDTs

"Can we make it work like Google Docs?"

It's a request that sounds simple until you try to build it.

Real-time collaboration is one of those features that feels like magic when it works. Two people typing into the same document, edits appearing seamlessly, no conflicts, no data loss. But under the hood, it's a carefully choreographed system of synchronization, merging, and conflict resolution.

As a senior engineer, I've come to see that real-time editing isn't just a UI challenge; it's an architectural one. Whether you're building a document editor, a collaborative whiteboard, or a multiplayer code environment, you eventually face a core decision: how do you model and reconcile concurrent changes to the same data?

Two major approaches have emerged to solve this: Operational Transforms (OT) and Conflict-free Replicated Data Types (CRDTs). Each has its philosophy, strengths, and trade-offs, and picking the right one isn't always obvious.

In this post, I'll walk through:

What OT and CRDTs are (in plain English)
How do they solve the problem of collaboration
Where each shines and where they fall short
How to choose the right one for your architecture

Whether you're building the next Notion or just curious how collaborative tech works under the hood, this post aims to give you a clear, practical foundation.

Why Collaborative Editing Is Harder Than It Looks

At a glance, real-time collaboration seems like a networking problem: sync edits between clients and you're good, right?

Not quite.

The real challenge lies in handling conflicting edits from multiple users, especially when those edits happen at the same time, in different places, or offline. Let's say two people insert text at the same position in a document. Whose change wins? In what order? And how do we ensure that everyone eventually sees the same result, without clobbering anyone's work?

Some of the core problems collaborative systems need to solve:

Concurrency: Multiple edits happening simultaneously on the same data
Ordering: Ensuring consistent operation ordering across clients
Conflict resolution: Resolving divergent versions without manual merges
Latency: Keeping edits fast and responsive, even over slow or flaky connections
Offline support: Handling edits made offline and merging them correctly later
Scalability: Syncing changes efficiently across many users and devices

In traditional single-user apps, you can trust that changes happen in a known order and context. In collaborative systems, you lose that guarantee; you now need to deal with partial views, out-of-order events, and race conditions between human intentions.

This is where OT and CRDTs come in. Both are designed to ensure eventual consistency, meaning that regardless of the edits made and their order, all users will end up with the same state. But they take radically different paths to get there.

Let's explore how each works and what that means for you as an engineer.

Operational Transforms: Old School, Still Useful

Operational Transforms (OT) is one of the earliest and most battle-tested approaches to real-time collaboration. If you've used Google Docs, you've likely seen it in action, without realizing it.

How It Works

At its core, OT is based on this idea:

When a user performs an operation (like inserting or deleting text), that operation is sent to a central server.
The server receives operations from all clients, determines their order, and transforms incoming operations to account for other concurrent operations.
The transformed operations are then broadcast back to all clients, ensuring that everyone consistently applies changes.

Imagine two users trying to insert a character at the same position. OT resolves this by shifting one operation forward (or backward) so the result makes sense for everyone.

This process of transforming operations against each other is the key. It allows each client to apply changes locally and immediately, while still converging to the same final state.

Strengths

Mature and Proven: OT has been used in production systems for decades.
Low-latency UX: Edits appear instantly (optimistic updates), with conflicts resolved on the backend.
Efficient: Operations are usually small, and the server controls ordering.

Weaknesses

Hard to Implement Correctly: Writing the transformation functions (e.g., for text, trees, etc.) is non-trivial and error-prone.
Server-Centric: OT relies on a central authority to maintain order. It's not ideal for offline-first or peer-to-peer apps.
Not Naturally Composable: Composing OTs for rich content (like lists inside tables inside documents) becomes complex.

Real-World Usage

Google Docs: Arguably the most famous use case
ShareDB: An open-source OT-based backend for JSON/document editing
Firepad: Collaborative code/text editor built on Firebase and OT

Example

Suppose we have this initial text:

"Hello"

User A inserts "X" at position 1 → insert(1, "X")
User B deletes character at position 2 → delete(2)

Initial:   "Hello"
User A:    insert(1, "X")  → "HXello"
User B:    delete(2)       → "Hllo"

Without transformation, applying both ops in the wrong order could break the text.

With OT, we transform each op against the other so both edits are preserved meaningfully.

CRDTs: Sync Later, Merge Automatically

While OT was designed for centralized collaboration, CRDTs (Conflict-free Replicated Data Types) were born from the needs of distributed and offline-capable systems. If OT is all about ordering and coordination, CRDTs take the opposite approach: let every device do what it wants, and merge later, automatically.

How CRDTs Work

CRDTs are special data structures that are mathematically designed to be:

Commutative (order doesn't matter)
Associative (grouping doesn't matter)
Idempotent (reapplying changes doesn't change the result)

This means you can:

Apply changes in any order
Synchronize without needing a central server
Merge state from any number of devices; even after long periods offline

There are two main types of CRDTs:

Operation-based CRDTs: Sync deltas (changes); smaller network load but require reliable delivery.
State-based CRDTs: Sync complete state periodically; simpler merge logic but heavier payloads.

Example: If two people both insert characters at the same spot, a CRDT structure ensures both are preserved and deterministically ordered.

Strengths

Perfect for Offline-First Apps: Clients can work independently and sync later.
No Central Server Required: Suitable for peer-to-peer and edge architectures.
Automatic Conflict Resolution: You don't need to write transform functions or deal with "merge hell."

Weaknesses

Heavier Resource Usage: May store tombstones, causal metadata, or complete histories.
Complex Data Structures: Lists, nested objects, and rich text require advanced CRDT variants.
Less Mature Ecosystem: Tooling is growing, but not as battle-tested as OT.

Real-World Usage

Automerge: JSON-like CRDT library for JavaScript
Yjs: Highly optimized CRDT framework, widely used in collaborative editors
Figma: Uses a hybrid model, with CRDT-like properties for real-time sync
Notion: Uses CRDT-based techniques for syncing changes offline

Example

Let's say the initial value is an empty list: []

User A inserts "A" at position 0 (offline)
User B inserts "B" at position 0 (offline)

Initial:   []

User A (offline):   insert(0, "A")  → ["A"]
User B (offline):   insert(0, "B")  → ["B"]

// When both clients sync:
CRDT merge:         → ["A", "B"]   // or ["B", "A"], based on internal IDs

Final (consistent): ["A", "B"]     // same across all devices

When both sync:

The CRDT merges these operations into a consistent order (e.g., [A, B] or [B, A]) based on causal metadata
No data is lost, and both clients reach the same result: no manual conflict resolution required

Choosing the Right Model: OT or CRDT?

There's no universal winner between Operational Transforms and CRDTs, it all comes down to your product's needs, constraints, and future roadmap.

Below is a practical guide to help you choose the right approach.

Decision Criteria

1. Do users need to collaborate offline?

Yes → CRDTs are the better fit. They allow users to work offline and merge changes later without conflicts.
No (always-online app) → OT may be simpler to implement and more efficient.

2. Is your system centralized or peer-to-peer?

Centralized: OT is optimized for client-server topologies.
Decentralized or P2P: CRDTs are built for this, with no need for a central authority.

3. Is document fidelity critical (e.g., rich text, layout precision)?

OT works well for linear content (like text), but complex structures require a lot of custom work.
CRDTs support nested and structured data (JSON, trees), but often need more memory and tuning.

4. How much control do you have over the client environment?

Full control (e.g., internal tool or company-wide app): OT might be fine, since you can enforce coordination rules.
Public, multi-device, or mobile-heavy apps: CRDTs handle edge cases like clock skew, unreliable networks, and user churn more gracefully.

5. Is data merge correctness more important than sync speed?

For instant collaboration with low conflict rates: OT can be faster.
For resilience and correctness even under messy conditions: CRDTs shine.

⚠️ Important: these models aren't mutually exclusive. Some modern tools (like Notion or Figma) use hybrid approaches: OT for performance-critical paths, CRDTs for background sync and recovery.

Closing Thoughts: Choose the Right Tool for the Right Collaboration

Real-time collaboration is no longer a niche feature, it's a baseline expectation in modern productivity tools. But building it is anything but trivial.

Both Operational Transforms and Conflict-free Replicated Data Types offer robust solutions to the problem of concurrent edits, but they approach it from fundamentally different angles:

OT shines in environments where coordination is possible and performance is critical.
CRDTs excel when flexibility, offline support, and distributed trust are essential.

As engineers, our job isn't to chase elegance or novelty, it's to ship systems that work for real people in the real world. Understanding the trade-offs between OT and CRDTs can help you build collaborative experiences that don't just sync; they scale, they recover, and they feel right.

Bottom line is: You don't just choose a sync algorithm; you choose a collaboration philosophy:

OT is about control and coordination.
CRDTs are about trust and eventual harmony.

Either way, it's not just about the data structure; it's about how your users interact, when they connect, and what they expect.

Darkø Tasevski @puritanic