Skip to content
CRDTs and Operational Transforms: Collaborative Editing Without Conflicts 2 min

CRDTs and Operational Transforms: Collaborative Editing Without Conflicts

SD
ScaleDojo
May 11, 2026
2 min read576 words
CRDTs and Operational Transforms: Collaborative Editing Without Conflicts

How Google Docs Handles 100 Simultaneous Editors

Open a Google Doc. Invite 10 people to edit it simultaneously. Everyone types, deletes, and reformats at the same time - and nobody sees a merge conflict. Ever. How? Google Docs uses Operational Transform, invented at Xerox PARC in 1989. Figma, on the other hand, uses CRDTs - a mathematically different approach that works without a central server. Both solve the hardest problem in collaborative software: concurrent edits.

The Concurrency Problem Visualized

The Document: 'HELLO'
                 01234

Alice sees: 'HELLO'   Bob sees: 'HELLO'

Alice: INSERT 'X' at position 2    Bob: DELETE char at position 1
       (wants 'HEXLLO')                  (wants 'HLLO')

Naive approach (both applied without coordination):
  Start:   H E L L O
  Alice:   H E X L L O  (inserted X at pos 2)
  +Bob:    H X L L O    (deleted pos 1 from Alice's result)
  Result:  'HXLLO' - WRONG! Alice wanted X between E and L.

Correct approach (OT transforms Bob's op):
  Alice's op applied first: 'HEXLLO'
  Bob's DELETE at pos 1 transforms:
    'Alice inserted before my position, shift +1'
    Bob now deletes pos 1 (still E): 'HXLLO'
  Wait, that is still wrong...

  The real OT: both ops transform against each other
  so the INTENT is preserved regardless of order.

Operational Transform (OT)

OT Architecture:

  [Alice]        [Server]        [Bob]
     |               |              |
     |  op: ins(2,X)  |              |
     |-------------->|              |
     |               |  op: del(1)  |
     |               |<-------------|
     |               |              |
     | Server transforms both ops:  |
     | T(ins(2,X), del(1)) = ins(1,X)|
     | T(del(1), ins(2,X)) = del(1) |
     |               |              |
     |  apply T(del) |  apply T(ins)|
     |<--------------|------------->|
     |               |              |
  Both converge to same document state.

  Key requirement: CENTRAL SERVER orders all operations.
  Without server ordering, OT is extremely hard to get right.
  Google Docs uses OT. Google Wave used OT (and had bugs).

CRDTs: Conflict-Free by Mathematics

CRDT Types and How They Work:

  G-Counter (Grow-only counter):
    Node A: {A:3, B:0}  Node B: {A:0, B:5}
    Merge: take max per node -> {A:3, B:5} = total 8
    Always correct. No conflicts possible.

  LWW-Register (Last Write Wins):
    Write(A, value='hello', t=100)
    Write(B, value='world', t=105)
    Merge: highest timestamp wins -> 'world'
    Deterministic. But earlier writes are silently lost.

  RGA (text editing):
    Each character has a unique ID: (node, sequence)
    'HELLO' = [(A,1,'H'), (A,2,'E'), (A,3,'L'), (A,4,'L'), (A,5,'O')]
    Alice inserts X after (A,2): [(A,1,'H'), (A,2,'E'), (A,6,'X'), ...]
    Bob deletes (A,2): mark as tombstone
    Both ops have unique IDs -> merge is unambiguous

  Libraries: Yjs, Automerge (used by many collab tools)

CRDTs vs OT: When to Use Which

Factor              OT                 CRDTs
------------------  -----------------  -------------------
Server required?    YES (ordering)     No (peer-to-peer)
Offline editing     Hard               Native support
Storage overhead    Low                Higher (metadata)
Network overhead    Low                Higher (IDs)
Correctness proof   Manual testing     Mathematical proof
Implementation      Very hard          Complex but proven
Used by             Google Docs        Figma, Linear, Notion
Best for            Server-centric     Offline-first, P2P

Interview Tip

When designing a collaborative editing system, say: 'For real-time collaboration, I would choose between OT and CRDTs based on the architecture. If I have a central server (like Google Docs), OT works well - the server orders all operations and transforms them to preserve intent. If I need offline-first or peer-to-peer sync (like a note-taking app), I would use CRDTs with a library like Yjs or Automerge. CRDTs guarantee conflict-free merges mathematically, even without a server, at the cost of higher storage overhead for the metadata that makes each operation unique.'

<
CRDTs and Operational Transforms: Collaborative Editing Without Conflicts - Architecture Diagram
Architecture overview
/blockquote>

Key Takeaway

OT transforms operations before applying them to handle concurrency - powerful but complex, requires a central server. CRDTs use mathematical properties to guarantee conflict-free merges - work peer-to-peer and offline. Modern collaboration tools like Figma and Linear use CRDTs for their conflict-free guarantees.

Enjoyed this article?

Share it with your network to help others level up their system design skills.

Discussion0

Join the Discussion

Sign in to leave comments, reply to others, or like insights.

Sign In to ScaleDojo

No comments yet. Be the first to start the thread!

Related Articles

Enjoyed this content?

Your support keeps us creating free resources

We put a lot of hours into researching and writing these guides. If it helped you, consider buying us a coffee. Every bit goes toward keeping ScaleDojo's content free and growing.

$

One-time payment via Stripe. ScaleDojo account required.

ScaleDojo Logo
Initializing ScaleDojo