Design Google Docs | Operation Transformation | CRDT
Multiple strategies for concurrent document modifications
Welcome to the 111 new subscribers who have joined us since last week.
If you aren’t subscribed yet, join 1000+ engineers and technical managers learning Advanced System Design.
Let’s design Google Docs, a real-time collaborative document editing system, focusing specifically on how it handles concurrent modifications when multiple users edit the same document simultaneously.
Google Docs is a classic example of a distributed collaboration system where low latency, data consistency, and real-time synchronization are critical. At the core of its design lies how it handles concurrency control — ensuring that multiple users can edit the same document seamlessly without conflicts or data loss.
We’ll explore three main approaches to managing concurrent edits:
Locking
Operational Transformation (OT)
Conflict-Free Replicated Data Types (CRDT)
When users collaborate in Google Docs:
Each client maintains a local copy of the document.
User edits (insert, delete, format change) are sent to a collaboration server.
The server processes operations, merges them, and broadcasts updates to other clients.
The system must ensure that all clients eventually converge to the same consistent document state — even if edits arrive out of order or network latency causes delays.
How do we resolve conflicts when multiple users edit the same part of the document at once?
Locking Approach (Pessimistic Concurrency Control)
Concept
The simplest concurrency control model is locking.
Under this approach, when a user edits a portion of the document (say a paragraph or sentence), the system locks that section so others can’t modify it until the lock is released.
How It Works
The document is divided into smaller segments (like paragraphs or text ranges).
When a user begins editing a segment, they request a lock from the server.
The server grants the lock if it’s free, and other users can only read the locked section.
Once the edit is complete and submitted, the lock is released, and changes are broadcasted to others.
Pros
Simple to reason about — ensures strong consistency.
Easy conflict prevention: two users can’t edit the same text concurrently.
Cons
Poor user experience — users may be blocked by others’ locks.
Doesn’t scale well for highly interactive editing.
High coordination overhead between clients and the server.
Operational Transformation (OT)
Operational Transformation (OT) is the technique Google Docs historically used for real-time collaboration.
It allows multiple concurrent operations (insertions, deletions, etc.) to be transformed and merged so that all users eventually see the same result, regardless of the order of operations.
How It Works
Each user’s edits are represented as operations (e.g., “insert character ‘A’ at position 5”).
When an operation is sent to the server, the server:
Assigns it a sequence number.
Transforms it against concurrent operations that have already been applied.
The transformed operation is then broadcasted to all clients.
Each client applies the transformed operation locally, ensuring all document states converge.
For example:
User A inserts “X” at position 2.
Simultaneously, User B deletes character at position 1.
When both operations reach the server, the delete operation is transformed to account for the new character inserted, maintaining a consistent document.
Pros
Real-time collaboration feels smooth — no locking or blocking.
Ensures eventual consistency while allowing concurrent edits.
Proven and well-optimized — used in Google Docs and Etherpad.
Cons
Complex transformation logic — handling all combinations of insert/delete operations is difficult.
Harder to implement for non-linear data structures (like tables, nested JSON documents).
Requires centralized coordination for assigning operation order.
Use Case
Ideal for text-based collaborative editing where real-time updates are crucial, and the system can rely on a central server to order and transform operations.
Conflict-Free Replicated Data Types (CRDT)
CRDTs are a more modern approach to distributed collaboration.
Unlike OT, CRDTs allow every client to operate completely independently, without needing a central transformation service. They rely on mathematical guarantees to ensure that all replicas eventually converge to the same state.
How It Works
The document is represented as a replicated data structure (e.g., a sequence CRDT for text).
Each edit is an operation that can be merged with others without coordination.
Each operation carries unique identifiers (timestamps or logical clocks) to determine order.
When edits are shared (eventually), all replicas merge them using deterministic merge rules.
For example:
User A inserts “X” at position 2 (assigned ID = A1).
User B inserts “Y” at position 2 (assigned ID = B1).
When merged, the system uses the IDs to deterministically order them (say, A1 < B1 → “XY”).
Pros
No central coordination — works even offline; perfect for decentralized or edge-first systems.
Strong eventual consistency by design.
Easier to reason about mathematically once implemented.
Works well for complex data structures (lists, maps, rich text).
Cons
Higher memory overhead — each character may carry metadata.
Merging logic is complex and can lead to performance trade-offs for large documents.
Harder to debug due to distributed causality.
Use Case
Best for fully decentralized collaborative editors, offline-first applications, or systems that require peer-to-peer editing (e.g., Figma’s shared canvas).
Check out a more detailed video coverage on my Youtube.
Thank you for your continued support of my newsletter and the growth to a 1k+ members community 🙏