Imagine you're working on a design document with your team.
There are five engineers editing the same document.
Alice
Bob
Charlie
David
EmmaAlice deletes a paragraph.
At the exact same moment...
Bob starts editing that paragraph.
Charlie pastes an entire page.
David changes the title.
Emma inserts an image.
Nobody gets a merge conflict.
Nobody loses their work.
Everyone's screen updates almost instantly.
How?
At first glance, this looks impossible.
The Naive Approach
Most people imagine something like this.
User Types
↓
Save Entire Document
↓
DatabaseEvery keystroke overwrites the document.
Now imagine Alice and Bob both press Save.
Alice Saves
↓
Version 2
--------------------
Bob Saves
↓
Version 1Bob's save completely overwrites Alice's changes.
Someone loses work.
This is called the Lost Update Problem.
Clearly, this approach doesn't scale.
What Actually Gets Sent?
Google Docs doesn't send the entire document every time you press a key.
Instead, it sends operations.
For example, suppose the document contains:
Hello WorldAlice inserts:
BeautifulInstead of sending:
Hello Beautiful WorldGoogle Docs sends something closer to:
Insert
Position: 6
Text: "Beautiful "Another user might send:
Delete
Position: 0
Length: 5Much smaller.
Much faster.
More importantly...
Operations can be transformed.
The Real Problem
Suppose the document says:
Hello WorldAlice deletes:
HelloAt exactly the same time...
Bob inserts:
Beautifulafter "Hello".
Alice's operation:
Delete
Position 0
Length 5Bob's operation:
Insert
Position 6
"Beautiful "Which operation should happen first?
If Bob's insert happens first...
Hello Beautiful WorldAlice now deletes five characters.
Result:
Beautiful WorldIf Alice's delete happens first...
The insertion position has changed.
Without adjustment...
Bob inserts at the wrong location.
Everyone ends up seeing different documents.
Operational Transformation (OT)
Google Docs originally solved this using Operational Transformation.
The idea is surprisingly clever.
Instead of applying operations immediately...
The server first checks:
"Has the document changed since this operation was created?"
If yes...
It transforms the operation.
Imagine Alice deletes:
HelloBob wants to insert at position:
6But after Alice's delete...
The document becomes:
WorldPosition 6 no longer exists.
The server transforms Bob's operation.
Instead of:
Insert
Position 6It becomes:
Insert
Position 1Now both operations produce the same final document for every user.
That's the magic behind Operational Transformation.
Another Example
Original document:
ABCDEAlice deletes:
BBob inserts:
Xafter B.
Without transformation:
ACXDEor
AXCDEdepending on who arrives first.
With OT...
Both users eventually see:
AXCDEEvery client converges to the same state.
But What Happens With Hundreds Of Users?
Google Docs isn't handling five people.
Some documents have hundreds of collaborators.
Every keystroke becomes an operation.
Alice
↓
Insert
↓
Server
↓
Broadcast
↓
Everyone ElseThe server continuously transforms incoming operations against operations that haven't yet reached every client.
This ensures everyone eventually reaches the same document.
Enter CRDTs
Another popular approach today is Conflict-Free Replicated Data Types (CRDTs).
Instead of transforming operations...
CRDTs make every operation mathematically mergeable.
Each edit carries a unique identifier.
Insert
ID: A101
Character: HAnother user might insert:
Insert
ID: B204
Character: iEven if edits arrive in different orders...
Every client eventually produces the same document.
No central transformation required.
CRDTs are heavily used in modern collaborative applications because they work well even when users go offline.
Version Vectors
How does the server know which edits you've already seen?
Using version information.
Imagine this.
Alice
Version 15
Bob
Version 13When Bob reconnects...
The server knows Bob is missing versions:
14
15Only those operations are sent.
This avoids transmitting the entire document repeatedly.
Version vectors also help detect conflicting updates and synchronize disconnected users efficiently.
Handling Network Delays
Suppose Alice is on fast Wi-Fi.
Bob is on a slow train connection.
Bob's operation arrives two seconds later.
Should it be ignored?
No.
Google Docs applies the operation...
Transforms it if necessary...
Then synchronizes every connected client.
Even delayed edits become part of the shared document.
What About Offline Editing?
Suppose your internet disconnects.
You continue typing for five minutes.
When you're back online...
Your client sends every pending operation.
Offline
↓
Store Operations Locally
↓
Reconnect
↓
Sync Missing Operations
↓
Merge ChangesThe document catches up automatically.
Why Not Lock The Document?
Imagine Google Docs locked the document whenever someone typed.
Alice Editing...
↓
Bob Waits
↓
Charlie Waits
↓
David WaitsCollaboration would become impossible.
Instead of locking...
Modern collaborative systems embrace concurrency and resolve conflicts intelligently.
Follow-Up Questions Interviewers Love
Why not save the entire document?
Because every keystroke would require sending megabytes of data and overwrite concurrent edits.
Operations are much smaller and easier to merge.
Why are CRDTs becoming more popular?
They allow multiple users to edit independently—even offline—and still guarantee that every replica eventually converges to the same state.
Does Google Docs use locks?
No.
Locks would serialize editing and destroy the collaborative experience.
Instead, systems rely on Operational Transformation or CRDTs to resolve concurrent edits.
Why are operations better than snapshots?
Operations capture intent.
Instead of saying:
"Here's the whole document."
they say:
"Insert this word here."
This makes synchronization dramatically more efficient.
Lessons Beyond Google Docs
This isn't just about documents.
The same ideas appear everywhere.
- Multiplayer games synchronizing player movements.
- Figma allowing multiple designers to edit simultaneously.
- Notion collaborative editing.
- Shared whiteboards.
- Real-time coding interviews.
- Pair programming tools.
Different products.
The same distributed systems problem.
Final Thoughts
Real-time collaboration isn't about repeatedly saving files.
It's about synchronizing operations, resolving conflicts, and ensuring that every user eventually sees the same document—even when edits happen simultaneously across different devices and networks.
The real challenge isn't handling one person's changes.
It's making hundreds of people feel like they're the only one editing the document.
That's the engineering magic behind tools like Google Docs.