Real-Time Collaboration Technologies — Vocabulary

The core trade-off: OT is server-centric (simpler algorithm but requires always-on server coordination); CRDT is distributed (complex data structure but no server needed for consistency).

OT (used in Google Wave, ShareDB): when two clients make concurrent edits, a server transforms operation B to account for operation A having already been applied, then sends the transformed B to all clients. This requires the server to see all operations and handle the transformation logic. Works well for a single-master architecture but is hard to implement correctly for multi-master. CRDT (used in Yjs, Automerge): each operation is a self-describing structure that can be merged with any other operation in any order and always produces the same result (commutativity and idempotency). No server needed for conflict resolution. Well-suited for P2P (WebRTC data channels), offline-first apps, and multi-region replication.

Key vocabulary:
• CRDT (Conflict-free Replicated Data Type) — data structure where concurrent operations always merge correctly without coordination
• OT (Operational Transform) — algorithm transforming operations to account for concurrent edits; requires server
• commutativity (CRDT) — the property that CRDT operations produce the same result regardless of application order

Data channels enable arbitrary P2P data transfer with the same NAT traversal that WebRTC uses for media — no separate server or connection needed.

RTCDataChannel properties: ordered (default: true) — like TCP, messages arrive in order; unreliable (maxRetransmits: 0) — like UDP, best-effort delivery for low-latency gaming or position updates; maxPacketLifeTime — drop old messages if not delivered within N milliseconds. CRDT sync via data channels: Yjs encodes document updates as compact binary diffs. When user A types, the Yjs update is encoded and sent over the data channel to all peers. Each peer applies the CRDT operation locally — guaranteed to converge to the same document state regardless of order. Offline edits accumulate and sync automatically when the data channel reconnects.

Key vocabulary:
• RTCDataChannel — WebRTC API for bidirectional arbitrary data transfer; uses SCTP over DTLS
• SCTP (Stream Control Transmission Protocol) — the transport protocol under data channels; supports ordered/unordered, reliable/unreliable delivery modes
• Yjs — a CRDT framework for building collaborative applications; supports text, maps, arrays, and custom types

SFU is the modern default for video conferencing — lower server cost, better quality — but MCU has value for low-bandwidth endpoints like mobile users on 3G.

SFU with 50 participants: each participant receives 49 streams. The SFU server just forwards packets — CPU is low. But the client needs enough bandwidth for 49 streams (typically reduced via simulcast to 200kbps × 49 = ~10Mbps for grid view — impractical). Real implementations use "active speaker detection": the SFU only forwards the streams of the last few active speakers (2-4) to each participant. This reduces client bandwidth to 2-4 × 800kbps = manageable. MCU with 50 participants: the server decodes all 50 streams and composites them into a grid video at real-time. Server CPU: enormous. But each client receives one 2Mbps stream. MCU shines for: dial-in phone participants (one audio stream), legacy endpoints, and very low bandwidth mobile users.

Key vocabulary:
• SFU (Selective Forwarding Unit) — media server forwarding streams without decoding; low CPU; each receiver downloads N streams
• MCU (Multipoint Control Unit) — mixes all streams server-side; high CPU transcoding; each receiver downloads 1 stream
• active speaker detection — technique reducing SFU bandwidth by forwarding only the speaking participants' streams

Presence = is this user connected; Awareness = what are they doing. Rich awareness (cursor sharing, selection highlighting) is what makes collaborative editing feel live.

Yjs Awareness protocol example: each user broadcasts a state object: { user: { name: 'Alex', color: '#f00' }, cursor: { index: 42, length: 0 }, isTyping: true }. All connected peers receive this state update and can render Alex's cursor at position 42 with a red colour and a "typing" indicator. Awareness state is intentionally ephemeral — it is not stored in the CRDT document; it is re-broadcast every time a user reconnects. Heartbeat interval (typically 30 seconds) keeps the presence list accurate: if a user's heartbeat stops, they are removed from the awareness state after a timeout.

Key vocabulary:
• presence — user online/offline status in a real-time session
• awareness — per-user ephemeral state (cursor, selection, typing) broadcast to all collaborators in real time
• Yjs Awareness protocol — lightweight CRDT-adjacent protocol for broadcasting presence/cursor state without persistence

Exponential backoff + jitter is the standard pattern — without jitter, thousands of clients reconnect simultaneously after a server restart, causing a "thundering herd" that crashes the server again.

Implementation: let delay = Math.min(baseDelay * 2**attempt, maxDelay); delay += Math.random() * jitterMs. On reconnect, the client must re-sync missed state: for CRDT apps, request all updates since last known clock; for event-sourced apps, fetch events since last sequence number; for snapshot-based apps, request the current state. The UI should clearly indicate the reconnection status: "Connection lost — reconnecting in 4 seconds" prevents users from thinking the app has crashed and prevents rage-clicking that generates duplicate data. WebSocket's onclose event fires with a reason code — check code 1001 (going away) vs. 1006 (abnormal closure) to distinguish intentional server shutdown from network failure.

Key vocabulary:
• exponential backoff — doubling retry delay with each failed attempt; prevents overwhelming a recovering server
• jitter — random variation added to backoff delay; prevents thundering herd when many clients reconnect simultaneously
• thundering herd — all disconnected clients reconnecting at the same moment after a server restarts; can crash the server again