System Type: Real-Time & Collaborative

Patterns, failure modes, and anti-patterns for systems with persistent connections and real-time state synchronization.

Connection Patterns

WebSocket

What it is. Full-duplex, persistent TCP connection upgraded from HTTP. Both sides can send frames at any time. When to use. Bidirectional communication with low latency — chat, collaborative editing, multiplayer games, live trading. When the server needs to push AND the client needs to push back frequently. When to avoid. Unidirectional server-to-client updates (SSE is simpler). Infrequent updates where polling is adequate. Environments where intermediaries (corporate proxies, older load balancers) silently kill long-lived connections. Key decisions. Binary vs text frames, subprotocol negotiation, per-message compression (permessage-deflate has CPU cost), ping/pong interval tuning.

Server-Sent Events (SSE)

What it is. Unidirectional server-to-client stream over a standard HTTP response. Built-in reconnection with Last-Event-ID. Works through HTTP/2 multiplexing natively. When to use. Live dashboards, notification feeds, stock tickers — anything where the server pushes and the client only needs HTTP requests for writes. When you want automatic reconnection semantics for free. When to avoid. Bidirectional real-time communication. Binary data. When you need more than ~6 concurrent connections per domain in HTTP/1.1 browsers (HTTP/2 eliminates this).

Long Polling

What it is. Client sends a request; server holds it open until there's data or a timeout, then responds. Client immediately sends the next request. When to use. Fallback when WebSocket and SSE aren't available. Environments with aggressive proxies. When connection frequency is low enough that the overhead is acceptable. When to avoid. High-frequency updates (each message requires a full HTTP round-trip). The per-request overhead is substantial compared to persistent connections.

WebTransport

What it is. Multiplexed, bidirectional transport built on HTTP/3 (QUIC). Supports both reliable streams and unreliable datagrams. No head-of-line blocking. When to use. Latency-sensitive applications where packet loss shouldn't stall unrelated streams — gaming, live media, telemetry. When you need unreliable delivery (datagrams) alongside reliable streams. When to avoid. Browser support is still limited. When WebSocket meets your latency requirements. When you don't control the server infrastructure to support HTTP/3.

Connection Lifecycle

Every persistent connection follows the same pattern: establish → authenticate → maintain → recover.

• Establish. Negotiate the connection (WebSocket upgrade, SSE stream open). Set initial parameters. The handshake is your one chance to reject bad clients cheaply.
• Authenticate. Pass a short-lived token during handshake (query param or first message). Never rely on cookies alone — CSRF is harder to prevent on WebSocket upgrades. Re-validate tokens periodically for long-lived connections.
• Heartbeat. Both sides send pings at a regular interval. If a pong is missed, the connection is considered dead. Tune the interval: too fast wastes bandwidth; too slow means minutes of stale "online" state. 30 seconds is a common default; 15 seconds for presence-critical systems.
• Reconnect. Exponential backoff with jitter. Include the last-seen sequence number so the server can resume without replaying the entire state. Cap the backoff (e.g., 60 seconds) — waiting 10 minutes to reconnect is indistinguishable from being offline.

Connection Multiplexing

…