DEV Community

Cover image for How Does Google Docs Handle Two People Editing the Same Line at the Exact Same Time?
Khushi Patel
Khushi Patel

Posted on

How Does Google Docs Handle Two People Editing the Same Line at the Exact Same Time?

#architecture #programming #productivity #webdev

Introduction

One of the most impressive features of Google Docs is real-time collaboration. Multiple users can edit the same document simultaneously and see changes appear almost instantly.

But what happens when two users edit the exact same line at the exact same moment?

How does Google Docs prevent one user's changes from overwriting another's? Is there a lock on the document? Does someone lose their changes?

The answer lies in a distributed systems technique called Operational Transformation (OT), combined with real-time synchronization architecture.

The Problem

Imagine a document containing:

Hello World
Enter fullscreen mode Exit fullscreen mode

Now consider two users:

User A

Adds:

Hello Beautiful World
Enter fullscreen mode Exit fullscreen mode

User B

At the same time adds:

Hello Amazing World
Enter fullscreen mode Exit fullscreen mode

Both users started editing from the same document version.

The challenge is:

  • Both changes are valid
  • Both arrive at the server simultaneously
  • Neither should overwrite the other
  • Everyone should eventually see the same document

Why Traditional Database Updates Fail

A typical CRUD system works like this:

Read Data
Modify Data
Update Data
Enter fullscreen mode Exit fullscreen mode

If two users update simultaneously:

User A -> Save
User B -> Save
Enter fullscreen mode Exit fullscreen mode

The second save overwrites the first.

This is known as a:

Lost Update Problem 

Final Result:
Hello Amazing World
Enter fullscreen mode Exit fullscreen mode

User A's changes disappear.

For collaborative editors, this is unacceptable.

Google's Solution: Operational Transformation (OT)

Instead of sending the entire document after every edit, Google Docs sends:

Operations
Enter fullscreen mode Exit fullscreen mode

Examples:

Insert "Beautiful" at position 6
Enter fullscreen mode Exit fullscreen mode 
Insert "Amazing" at position 6
Enter fullscreen mode Exit fullscreen mode

The server receives operations rather than complete document snapshots.

Understanding Operations

Original text:

Hello World
Enter fullscreen mode Exit fullscreen mode

User A Operation 

Insert "Beautiful " at position 6
Enter fullscreen mode Exit fullscreen mode

User B Operation 

Insert "Amazing " at position 6
Enter fullscreen mode Exit fullscreen mode

Both operations target the same location.

Without conflict resolution:

Hello Beautiful World
Enter fullscreen mode Exit fullscreen mode

or

Hello Amazing World
Enter fullscreen mode Exit fullscreen mode

One edit wins.

Google Docs does something smarter.

Operational Transformation in Action

Server receives:

Operation A:
Insert "Beautiful " at position 6
Enter fullscreen mode Exit fullscreen mode

Then receives:

Operation B:
Insert "Amazing " at position 6
Enter fullscreen mode Exit fullscreen mode

The second operation is transformed based on the first.

Instead of:

Insert at position 6
Enter fullscreen mode Exit fullscreen mode

it becomes:

Insert at position 16
Enter fullscreen mode Exit fullscreen mode

because the document has already grown.

Final result:

Hello Beautiful Amazing World
Enter fullscreen mode Exit fullscreen mode

Both users' edits survive.

Real-Time Architecture 

          User A
             |
             |
             v
      WebSocket Server
             ^
             |
             |
          User B
Enter fullscreen mode Exit fullscreen mode

Google Docs maintains a persistent connection using:

  • WebSockets
  • Real-time event streams
  • Version tracking

Every edit is sent as a tiny operation rather than a full document.

Step-by-Step Flow

Step 1

Both users load:

Version 100
Enter fullscreen mode Exit fullscreen mode

Step 2

User A sends:

Insert "Beautiful"
Version 100
Enter fullscreen mode Exit fullscreen mode

Step 3

User B sends:

Insert "Amazing"
Version 100
Enter fullscreen mode Exit fullscreen mode

Step 4

Server processes User A first.

Document becomes:

Version 101
Enter fullscreen mode Exit fullscreen mode

Step 5

Server notices User B is based on:

Version 100
Enter fullscreen mode Exit fullscreen mode

while current document is:

Version 101
Enter fullscreen mode Exit fullscreen mode

Now OT transforms User B's operation before applying it.

Step 6

Document updates successfully.

Everyone eventually sees:

Hello Beautiful Amazing World
Enter fullscreen mode Exit fullscreen mode

What About Cursor Positions?

Imagine you're typing while another person inserts text before your cursor.

Without adjustment:

Cursor jumps randomly
Enter fullscreen mode Exit fullscreen mode

Google Docs tracks:

  • Cursor position
  • Selection ranges
  • User presence

When operations are transformed, cursor positions are transformed too.

This is why your typing experience remains smooth even when dozens of users are editing.

Does Google Lock the Document?

No.

Document locking would be terrible for collaboration.

Imagine:

User A is editing line 20
Enter fullscreen mode Exit fullscreen mode

Everyone else would have to wait.

Instead, Google allows:

Concurrent editing
Enter fullscreen mode Exit fullscreen mode

and resolves conflicts intelligently.

This provides a much better user experience.

Modern Alternative: CRDTs

Many newer collaborative systems use:

Conflict-free Replicated Data Types (CRDT)

Used by:

  • Figma
  • Notion (parts of architecture)
  • Modern collaborative editors
  • Offline-first applications

CRDTs allow clients to merge changes without requiring a central transformation server.

Benefits:

  • Better offline support
  • Easier synchronization
  • High scalability

Google Docs was originally built using Operational Transformation, although modern collaborative systems increasingly adopt CRDT-based approaches.

System Design Architecture 

                    +----------------+
                    | Document Store |
                    +----------------+
                            ^
                            |
                            |
+--------+         +----------------+         +--------+
| User A | <-----> | Sync Server    | <-----> | User B |
+--------+         +----------------+         +--------+
                            |
                            |
                    Operational
                   Transformation
                            |
                            v
                    Document State
Enter fullscreen mode Exit fullscreen mode

The Sync Server is responsible for:

  • Receiving operations
  • Version tracking
  • Conflict resolution
  • Operation transformation
  • Broadcasting updates

Interview Perspective

A common System Design interview question is:

Design Google Docs.

Expected discussion points:

  1. WebSockets for real-time communication
  2. Operational Transformation or CRDT
  3. Version numbers
  4. Conflict resolution
  5. Document persistence
  6. Cursor synchronization
  7. Horizontal scaling of collaboration servers

Mentioning OT and CRDT immediately demonstrates a strong understanding of collaborative systems.

Key Takeaways

  • Google Docs does not lock documents during editing.
  • Users send operations instead of entire document snapshots.
  • Operational Transformation resolves simultaneous edits.
  • The server transforms conflicting operations so both changes can survive.
  • WebSockets provide low-latency synchronization.
  • Cursor positions are transformed along with document changes.
  • Modern systems often use CRDTs as an alternative approach.

The magic behind Google Docs is not preventing conflicts—it's intelligently transforming and merging edits so that every user eventually sees the same consistent document.

Top comments (0)