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

High-Level Architecture

Detailed Component Architecture

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

Workshop note · added for the website’s common reading format

1. Editor clients: Apply local edits immediately and track operations awaiting server acknowledgement.
2. WebSocket gateway: Authenticate users and route each connection to its active document session.
3. Collaboration engine: Transform concurrent operations against accepted history so clients converge on a shared document.
4. Presence service: Broadcast transient cursor state separately from durable document changes.
5. Operation log: Append accepted operations for recovery, replay, and reconnect catch-up.
6. Document store: Periodically snapshot the document so replay cost stays bounded.

Workshop note · added for the website’s common reading format

Start with the dominant access pattern of Real-Time Collaboration. Operation log is one place to inspect capacity and tail latency. Measure before introducing a cache: define the cache key, invalidation policy, stale-data budget, and cold-start behavior.

Batch independent work where the latency budget allows it. Bound queues and concurrency, and verify that an optimization does not move the bottleneck to a dependency.

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

Workshop note · added for the website’s common reading format

Use explicit session ownership and recovery rules to avoid concurrent authoritative editors.

Set service-level objectives for the user-visible path, then map its dependencies. Define bounded retries with jitter, deadlines, and backpressure. Keep a degraded mode that protects authoritative state, and test recovery instead of treating replication as a backup.

For Real-Time Collaboration, pay special attention to Operation log, Document store, Offline buffer when deciding failure domains and recovery procedures.

Production Architecture

Workshop note · added for the website’s common reading format

Rebuild Real-Time Collaboration from memory, then change one assumption: ten times more traffic, a new region, or a stricter consistency requirement. Which component must change first—and which does not?

Compare Collaboration engine with the same boundary in a related design. Write down one alternative you rejected, what it would simplify, and when you would choose it instead. Follow the source link at the end of this article to explore the original document.

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.