WebSocket and Real-Time Communication

Persistent connections for chat, live feeds and notifications when polling is too slow.

IntermediateTheory11 min read

Read these first

Content Delivery Network

Polling vs push

Aspect	Short polling	WebSocket
Connection	New HTTP request every N seconds	One long-lived TCP connection
Latency	Up to poll interval (e.g. 5s)	Sub-second server push
Overhead	High — repeated headers	Low after handshake
Server load	Scales with poll frequency × users	Stateful connections per user

Connection
Short pollingNew HTTP request every N seconds
WebSocketOne long-lived TCP connection
Latency
Short pollingUp to poll interval (e.g. 5s)
WebSocketSub-second server push
Overhead
Short pollingHigh — repeated headers
WebSocketLow after handshake
Server load
Short pollingScales with poll frequency × users
WebSocketStateful connections per user

Long polling and SSE sit between these extremes; WebSocket wins for bidirectional real-time.

WebSocket handshake

WebSockets start as HTTP, then upgrade:

Java

GET /ws/live/chat HTTP/1.1
Host: live.streamhub.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

After 101, both sides send framed messages — text or binary — without new HTTP requests.

Client

Serverpersistent socket

Clientreal-time update

One persistent connection replaces repeated HTTP round-trips.

Message protocol design

Define a schema so clients and servers agree on event types:

Java

// Client → server: join live room
{ "type": "join", "room_id": "live_v_9182", "token": "eyJ..." }

// Server → client: viewer count update
{ "type": "viewer_count", "room_id": "live_v_9182", "count": 48291 }

// Server → client: new chat message
{ "type": "chat", "user": "creator_42", "text": "Thanks for watching!", "ts": 1712001234 }

Use JSON for readability in early products; protobuf or MessagePack at extreme scale.

Scaling WebSocket servers

WebSocket connections are stateful — a user stays pinned to one server for the session's lifetime.

Scaling strategies

Sticky sessions — LB routes by cookie or connection ID to the same node.
Pub/sub backplane — Redis Pub/Sub or Kafka bridges messages between WS nodes.
Dedicated WS tier — separate autoscaled pool from stateless REST API.
Connection limits — plan ~50K–100K connections per well-tuned node (varies by hardware).

Java

User A ──WS──► Node 1 ──┐
                        ├── Redis Pub/Sub ──► Node 2 ──WS── User B
User C ──WS──► Node 1 ──┘

When User A sends a chat message to Node 1, Node 1 publishes to Redis; Node 2 (holding User B's connection) receives and forwards.

StreamHub live features

StreamHub uses WebSockets for:

Live viewer count on premiere pages.
Real-time chat during streams.
Creator "go live" notifications to followers.

REST handles video metadata and uploads; WebSocket handles ephemeral, high-frequency events.

Java

// Client connection (simplified)
const ws = new WebSocket('wss://live.streamhub.com/ws/live/chat');
ws.onopen = () => ws.send(JSON.stringify({ type: 'join', room_id: 'live_v_9182' }));
ws.onmessage = (e) => handleEvent(JSON.parse(e.data));

Alternatives worth mentioning

Technology	Direction	Best for
SSE (Server-Sent Events)	Server → client only	Live feeds, stock tickers
Long polling	Simulated push over HTTP	Legacy browser support
WebRTC	Peer-to-peer media	Video calls, ultra-low-latency
MQTT	Pub/sub over TCP	IoT, mobile push backends

SSE (Server-Sent Events)
DirectionServer → client only
Best forLive feeds, stock tickers
Long polling
DirectionSimulated push over HTTP
Best forLegacy browser support
WebRTC
DirectionPeer-to-peer media
Best forVideo calls, ultra-low-latency
MQTT
DirectionPub/sub over TCP
Best forIoT, mobile push backends

Reliability concerns

Heartbeats — ping/pong frames detect dead connections; clients reconnect with exponential backoff.
Auth on connect — validate JWT in the upgrade request; re-auth on token expiry.
Backpressure — slow clients should not block the server; drop or queue with limits.
Graceful deploy — drain connections before killing a node; clients reconnect to healthy peers.

Java

# Reconnect policy (client-side)
initial_delay_ms: 1000
max_delay_ms: 30000
multiplier: 2
max_retries: unlimited   # until user leaves page

Quick recall

Everything you need if you only revisit this box.

WebSockets provide full-duplex persistent connections after an HTTP upgrade.
Prefer WebSocket over polling when latency matters (chat, live counts, notifications).
Scale with sticky routing plus Redis/Kafka pub/sub between WS nodes.
Define a JSON message schema with typed events for client and server.
Implement heartbeats, auth on connect, and client reconnect with backoff.
StreamHub uses WebSocket for live chat and viewer counts; REST for CRUD.

Test yourself

Answer these before moving on — recall is what makes it stick.