Imagine two users Alice and Bob editing the same Google Doc at the same time.
Initial text: Hello world
Now:
•Alice types “beautiful ” before “world” → Insert(6, "beautiful ")
•Bob deletes “world” → Delete(6, 5)
Both edits happen simultaneously on different devices.
Each user’s browser applies the edit locally for instant feedback.
So Alice sees:Hello beautiful world
Bob sees:Hello
The problem: When their changes reach the server, the document states don’t match.
If we just apply one after the other, we might lose a user’s edit.
So how does Google Docs merge them correctly?
The Core Idea: Operational Transformation (OT)
Google Docs doesn’t sync entire documents, it syncs operations.
Every operation carries:
•Position (where to apply the change)
•Type (insert/delete)
•Content (what’s inserted/deleted)
•Version info (what state this operation was based on)
When two operations conflict, Google Docs uses OT to transform one operation in the context of the other.
In our case:
1The server receives both operations.
2It sees they’re based on the same version.
3It transforms them so that both effects survive.
Result: Hello beautiful
Both Alice’s and Bob’s changes are merged correctly, preserving intent.
Modern Alternative: CRDT (Conflict-free Replicated Data Types)
OT needs a central server to resolve transformations.
Modern editors like Figma, Notion, and Yjs use CRDTs, which allow conflict-free sync even without a central authority.
Each operation carries enough causal info to merge automatically, so even if users go offline, edits merge later without conflicts.
TL;DR
Google Docs keeps real-time collaboration consistent through Operational Transformation, ensuring every user’s intent is preserved even during concurrent edits.
Modern systems evolve this idea using CRDTs for distributed, offline-first editing.
#SystemDesign #DistributedSystems #GoogleDocs #CRDT #OperationalTransformation