The Cursor Collision That Couldn't Happen: How Two Google Engineers Solved the 'Same Cell, Same Time' Problem — And Built the Algorithm That Lets a Million People Edit at Once

October 2010. Building 43, Google Campus, Mountain View.

David Glazer and Sam Schillace stared at a laptop screen showing a single Google Sheets cell. Two cursors blinked inside it — one blue, one green. Both engineers started typing simultaneously. Blue typed "Hello". Green typed "World".

The cell should have exploded into chaos. One person's text should have overwritten the other's. Someone should have lost their work.

Instead, the cell read: "HelloWorld".

Both edits survived. No data lost. No conflicts. No angry error messages.

"How the hell did that just work?" Glazer whispered.

Schillace grinned. "Because we just implemented the most elegant algorithm most people have never heard of."

The algorithm was called Operational Transformation. And it was about to change how the internet collaborated forever.

The Impossible Problem Nobody Thought About

Before Google Docs launched in 2006, real-time collaboration was mostly science fiction. You emailed files back and forth. You used "Track Changes" in Word. You shouted "Don't touch the file, I'm editing it!" across the office.

The technical problem seemed unsolvable: How do you let multiple people edit the same document simultaneously without their changes destroying each other?

The naive approach — "last write wins" — was a disaster. If you typed "Hello" and I typed "World" at the same time in the same spot, one of us would see our work vanish. Unacceptable.

Locking the document while someone edited? Defeats the entire purpose of real-time collaboration.

The Google Docs team needed something smarter. Something that could reconcile concurrent edits without losing anyone's intent.

They found it in a 1989 research paper from Xerox PARC.

The Xerox Secret: How Jupiter Solved Collaboration in 1989

In 1989, two researchers at Xerox PARC — David Nichols and Curtis Ellis — were building a system called Jupiter. They wanted multiple people to edit the same text file over a network.

They invented Operational Transformation.

Here's the core insight: Don't send the final state of the document. Send the operations that change it.

Instead of sending "the cell now contains 'Hello'", you send: insert('H', position=0), insert('e', position=1), insert('l', position=2)...

Why? Because operations can be transformed to account for concurrent edits.

Imagine this scenario:

• Alice has the text: "cat"
• Bob has the text: "cat"
• Alice inserts "fat " at position 0 → "fat cat"
• Bob simultaneously deletes "c" at position 0 → "at"

Both send their operations to the server. The server receives them in some arbitrary order. What should the final text be?

This is where the magic happens. Operational Transformation defines transform functions that adjust operations based on what happened concurrently.

When the server receives Bob's delete(0) after Alice's insert("fat ", 0), it transforms Bob's operation:

• Original: delete(0)
• Transformed (because Alice inserted 4 characters at position 0): delete(4)

The server applies both operations:

1. insert("fat ", 0) → "fat cat"
2. delete(4) → "fat at"

Both clients converge to the same final state: "fat at".

No conflicts. No lost data. Just math.

The Google Docs Bet: Building Collaboration on OT

When Google acquired Writely in 2006 (which became Google Docs), Sam Schillace brought a radical idea: build the entire collaboration stack on Operational Transformation.

The team faced three brutal challenges:

1. The Transform Function Complexity

For every type of operation (insert, delete, format, etc.), you need a transform function that handles every possible concurrent operation. The number of cases explodes fast.

For simple text, you need:

• transform(insert, insert)
• transform(insert, delete)
• transform(delete, insert)
• transform(delete, delete)

For rich text documents? Add formatting operations. For spreadsheets? Add cell references, formulas, row/column operations. The engineering becomes a nightmare.

The Google Docs team spent months writing and testing transform functions. Every edge case — deleting a range that another user just formatted, inserting text into a paragraph another user just deleted — needed a mathematically correct transformation.

2. The Central Server Requirement

OT requires a central server to establish a total ordering of operations. The server receives operations from all clients, transforms them against each other in a consistent order, and broadcasts the transformed operations back.

Why? Because OT's correctness depends on everyone agreeing on the order operations happened. If two clients disagree on the order, they diverge into different final states.

This meant Google Docs couldn't work offline (initially). No internet? No collaboration. The server was the single source of truth.

3. The Undo/Redo Minefield

Here's a brain-bender: How do you implement Undo in a collaborative document?

If you type "Hello", then I type "World", then you hit Undo... what should happen? Should your "Hello" disappear? Should my "World" stay?

OT solves this by treating Undo as just another operation. When you undo, the client generates an "inverse operation" (e.g., if you inserted "Hello", undo generates delete("Hello")) and sends it through the same OT pipeline.

The server transforms it against any concurrent operations and broadcasts it. Your undo doesn't erase my work — it undoes your work while preserving the intent of everyone else's edits.

Intent preservation. That was the holy grail.

The Moment It All Clicked: The 2010 Sheets Launch

When Google Sheets launched with real-time collaboration in 2010, the team demonstrated the impossible live on stage.

Two engineers, two laptops, one spreadsheet. They typed into the same cell simultaneously. They edited the same formula. They inserted rows while the other person was referencing them.

Nothing broke. No conflicts. No lost data.

The audience gasped. Because nobody had seen real-time multiplayer editing at this scale before. Behind the scenes, the OT engine was transforming operations at millisecond latency:

• User A: insert("=SUM(A1:A10)", cell=B1)
• User B: insertRow(5)
• Server transforms A's operation: insert("=SUM(A1:A11)", cell=B1) (because the range now includes the new row)

The formula updated automatically. Intent preserved.

The Challenger: Why CRDTs Are Eating OT's Lunch

But by 2015, a new approach was gaining traction: Conflict-free Replicated Data Types (CRDTs).

CRDTs flipped the OT model on its head. Instead of transforming operations through a central server, CRDTs used data structures that mathematically guarantee eventual consistency without coordination.

Here's the core idea: Design your data structure so that any two replicas, after receiving the same set of operations in any order, converge to the same state.

No central server needed. No operation ordering required. Just pure, commutative math.

Example: The LWW-Register (Last-Write-Wins)

The simplest CRDT: every write includes a timestamp. When merging, pick the write with the latest timestamp. If you and I both edit a cell, the later edit wins. Simple. Convergent. But lossy — someone's work disappears.

Example: The G-Counter (Grow-Only Counter)

For a collaborative counter (like "likes" on a post), each client maintains its own counter. The global count is the sum of all client counters. Operations commute: increment from client A + increment from client B = same result regardless of order.

Example: Sequence CRDTs (RGA, YATA)

For collaborative text editing, sequence CRDTs like RGA (Replicated Growable Array) assign each character a globally unique ID and a position relative to other characters. When you insert "H" between "e" and "o", it gets an ID that encodes "I come after 'e' and before 'o'".

When two users concurrently insert characters in the same spot, the CRDT uses a deterministic tie-breaker (like client ID) to decide the order. Both clients independently arrive at the same final order. No server needed.

The Great Divide: OT vs CRDT

OT Wins:

• Smaller operation size (just the change, not the metadata)
• Easier to preserve user intent (explicit transform functions)
• Battle-tested at Google/Microsoft scale

CRDT Wins:

• Offline-first (no central server needed)
• Simpler mental model (eventually consistent, commutative merges)
• Better for peer-to-peer architectures (like Figma's multiplayer canvas)

The Trade-off:

OT is complex but precise. CRDTs are simple but require more metadata (every character needs a unique ID).

Google Docs still uses OT. Figma uses a custom CRDT. The open-source world has rallied around CRDTs (Yjs, Automerge) because they enable local-first software — apps that work offline and sync peer-to-peer.

The Implementation War: Who's Using What?

OT in Production:

• Google Docs/Sheets (custom implementation)
• Microsoft Office Online (custom OT variant)
• ShareDB (open-source OT framework)

CRDTs in Production:

• Figma (custom CRDT for canvas elements)
• Notion (hybrid: CRDTs for blocks, OT-like transforms for text)
• Yjs (open-source CRDT, powers TipTap, ProseMirror, Monaco)
• Automerge (open-source CRDT with time-travel debugging)

The Cursor Presence Problem:

Neither OT nor CRDTs solve cursor positions elegantly. If I'm editing at position 10 and you insert 5 characters at position 3, where should my cursor move?

Google Docs uses a separate presence system: cursors broadcast their position in terms of stable anchors (like "after the word 'Hello'") rather than raw offsets. When the document changes, cursors recalculate their position based on the anchor.

Figma does the same for selection boxes on the canvas.

The Math That Makes It Work: The OT Puzzle

For the engineers who want the deep cut, here's the mathematical guarantee OT provides:

TP1 (Transformation Property 1): If operations O1 and O2 are concurrent, then: O1' = transform(O1, O2) and O2' = transform(O2, O1) such that: apply(apply(S, O1), O2') = apply(apply(S, O2), O1')

In English: No matter which order the operations arrive, after transformation, both clients end up in the same state.

TP2 (Transformation Property 2): If you transform O1 against O2, then transform the result against O3, it should be the same as transforming O1 against the composition of O2 and O3.

This ensures that a sequence of transformations doesn't drift.

Proving TP1 and TP2 for every operation type is hard. Google's OT implementation includes thousands of lines of tests just to verify these properties hold.

CRDTs sidestep this by making the data structure itself commutative. The merge operation is provably associative and commutative by construction. No transformation needed.

The Legacy: Why a Million Spreadsheets Don't Explode

Today, Google Sheets handles millions of simultaneous collaborative sessions. Students doing group projects. Remote teams building quarterly plans. Hundred-person companies tracking inventory in real-time.

Two cursors in the same cell? Happens a thousand times a second. Nobody loses their work.

Because in 2010, a team of engineers at Google bet everything on a 30-year-old algorithm from Xerox PARC. They wrote transform functions for every edge case. They built a central server that could order operations at Google scale. They solved Undo in a multiplayer context.

And they made the impossible — two people editing the same cell at the same time — feel like magic.

Operational Transformation isn't the only answer anymore. CRDTs are rising fast, especially in local-first, peer-to-peer apps. But OT proved it could be done. It gave us the blueprint.

The next time you see a collaborator's cursor blink in your document, remember: underneath that simple blinking cursor is one of the most elegant algorithms ever written. A mathematical proof that conflict doesn't have to mean loss.

Just transformation.