Real-Time Collaboration

Problem Statement & Requirements

Functional Requirements

• Concurrent editing — multiple users edit the same document simultaneously
• Real-time sync — edits appear on all collaborators' screens within ~100 ms
• Conflict resolution — concurrent edits to the same section must merge correctly without data loss
• Cursor & selection sync — see where other users' cursors are and what they've selected
• Presence — show who is currently viewing/editing the document
• Undo/redo — per-user undo that doesn't revert other users' changes
• Version history — view and restore previous versions of the document
• Comments & suggestions — inline annotations anchored to document positions
• Offline editing — queue local changes and sync when reconnected
• Rich text — bold, italic, headings, lists, tables, images

Non-Functional Requirements

• Low latency — local edits appear instantly (< 16 ms); remote edits visible within 100-200 ms
• Consistency — all users converge to the same document state (eventual consistency)
• High availability — documents always editable, even during partial outages
• Scalability — support millions of documents, thousands with 50+ concurrent editors
• Durability — no data loss; every accepted edit is persisted
• Ordering — causal ordering of operations preserved

Out of Scope

• Spreadsheet-specific features (cell formulas, recalculation)
• Presentation/slides editing
• Drawing/whiteboard (requires different data model)
• Real-time voice/video (that's WebRTC)

Scale Estimations

Users & Documents

Operations

Storage

Network

This first layer defines the system boundary. The next chapters add application logic and data dependencies. After examining the request paths and tradeoffs, we will add operational safeguards and bring the complete architecture together.

Detailed OT Client-Server Protocol

Client State Machine

Server-Side OT Processing

Document Storage & Versioning

Snapshot + Operation Log Model

Data Model

The Core Problem: Concurrent Editing

Algorithm Deep Dive: OT vs CRDTs

Option 1: Operational Transformation (OT)

OT Transform Rules

OT Architecture (Google Docs Approach)

Option 2: CRDTs (Conflict-free Replicated Data Types)

OT vs CRDT Comparison

An editor applies an operation locally, sends it with a stable ID, and receives acknowledgement of its accepted position or version. Other editors apply the corresponding remote operation under the chosen OT or CRDT rules. A reconnecting client exchanges missing operations or loads a snapshot before replaying outstanding local changes.

Batch nearby edits when that does not make typing feel delayed. Cursor movement and presence can be throttled or dropped; document operations cannot be discarded on the same basis. Periodic snapshots bound how much history a new participant must replay, but retain enough operation history to reconcile supported offline sessions.

Cursor & Selection Sync

Presence System

Rich Text Document Model

Comments & Suggestions

Document Session Management

Offline Editing

Undo/Redo in Collaborative Context

Tradeoffs & Design Decisions Summary

Persist accepted document operations before acknowledging durable acceptance. If a collaboration server fails, reconnecting clients use stable operation IDs to avoid applying retries twice. Separate ephemeral presence from document state, and test recovery with two editors who kept working offline from different revisions.

High-Level Architecture

Detailed Component Architecture

Production Architecture

Have one editor delete a paragraph while another inserts a sentence inside it. Describe the intended result before picking an algorithm. Then undo the deletion. This small exercise exposes whether the product’s editing semantics match the conflict-resolution rules rather than merely producing the same bytes on every device.

Interview Tips

1. Start by stating the core challenge — "The fundamental problem is: two users edit the same word at the same time. How do we merge without losing either edit?" This frames everything.

2. Draw the OT diamond — Show state S, two concurrent ops, and how transformation produces the same result S' regardless of order. This visual sells your understanding.

3. Compare OT vs CRDT — Even if you choose one, show you know the other. "OT requires a central server but uses less memory. CRDTs work peer-to-peer but carry tombstone overhead."

4. Client state machine is a great deep dive — Show SYNCHRONIZED → AWAITING_ACK → AWAITING_ACK_WITH_BUFFER. This proves you understand the practical implementation, not just theory.

5. Don't forget cursors — Interviewers love the cursor sync detail. "Cursor positions must be transformed against incoming operations. We throttle cursor updates to 20/sec and use unreliable delivery."

6. Snapshot + op log for storage — "We don't store the full document on every keystroke. We take snapshots every 1,000 ops and replay the op log to reconstruct any revision."

7. Session stickiness is essential — "All operations for a document must route to the same server node. This gives us single-threaded OT — no distributed consensus needed for operation ordering."

8. Mention undo correctness — "Per-user undo stack. When you hit Ctrl+Z, it reverts YOUR last operation, not someone else's. The inverse is transformed against all subsequent ops."

9. Version history comes for free — "Because we store the operation log, version history is just 'replay ops from snapshot to revision N.' Diff is computed from the op sequence."

10. Name real implementations — "Google Docs uses server-centric OT. Figma uses CRDTs. Yjs is the most popular open-source CRDT library." This shows industry awareness.