WebSockets

WebSocket is a communication protocol that provides full-duplex, persistent connections between a client and server over a single TCP connection. Unlike HTTP (request-response), WebSocket allows both sides to send data at any time without the overhead of establishing a new connection for each message.

Why This Matters

WebSockets power real-time features: chat applications, live notifications, stock tickers, collaborative editing, and online gaming. Understanding when to use WebSockets vs HTTP polling vs SSE is a key system design decision.

The Building Blocks

• Full-duplex: Both client and server can send messages independently at any time.
• Persistent connection: After the initial HTTP upgrade handshake, the connection stays open. No repeated TCP/TLS handshakes.
• Low overhead: WebSocket frames have 2-14 bytes of header vs HTTP's 100+ byte headers per request.
• When to use: Real-time chat, live updates, collaborative editing, gaming, financial data streaming.
• When NOT to use: Standard CRUD APIs, infrequent updates, one-way data (use SSE instead).

Under the Hood

A WebSocket connection starts as a normal HTTP request with an Upgrade header. The server responds with 101 Switching Protocols, and the connection is upgraded to WebSocket. From this point, both sides can send messages freely. The connection persists until explicitly closed by either side.

Scaling WebSockets is harder than scaling HTTP because connections are stateful. You need sticky sessions or a pub/sub system (Redis) so any server can push messages to any connected client.

How Companies Actually Do This

Slack uses WebSockets for real-time messaging — every message, typing indicator, and presence update is delivered via WebSocket.

Figma uses WebSockets for real-time collaborative design, syncing cursor positions and design changes between users.

Binance streams real-time cryptocurrency prices to millions of connected clients via WebSocket.

Common Pitfalls

1. Using WebSockets for everything — simple API calls should use HTTP
2. Not handling reconnection — networks are unreliable, connections drop
3. Not implementing heartbeats — idle connections may be silently closed by firewalls/proxies

Interview Questions Worth Practicing

1. When should you use WebSockets vs HTTP long polling vs SSE?
2. How do you scale WebSocket connections across multiple servers?
3. How do you handle reconnection and message ordering?
4. What happens when a WebSocket server goes down?

The Tradeoffs

• WebSocket vs HTTP Polling: WS is real-time but stateful; polling is simpler but wastes bandwidth.
• WebSocket vs SSE: WS is bidirectional; SSE is server-to-client only but simpler and auto-reconnects.
• Scalability: Each WebSocket connection consumes a TCP socket. A single server can handle 100K-1M connections; beyond that, you need horizontal scaling with a message broker.

Related Topics

• long-polling-vs-websockets
• Pub/Sub
• HTTP and HTTPS
• Event-Driven vs Request-Driven

Original DosiBridge notes for WebSockets

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study WebSockets is to connect the concept to an integration boundary where bad contracts become customer-facing outages. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Contract Evolution: For WebSockets, decide the contract evolution before choosing tools; otherwise the design looks clean but fails when websockets changes.
• Idempotency: For WebSockets, decide the idempotency before choosing tools; otherwise the design looks clean but fails when websockets changes.
• Pagination: For WebSockets, decide the pagination before choosing tools; otherwise the design looks clean but fails when websockets changes.
• Error Shape: For WebSockets, decide the error shape before choosing tools; otherwise the design looks clean but fails when websockets changes.
• Consumer Compatibility: For WebSockets, decide the consumer compatibility before choosing tools; otherwise the design looks clean but fails when websockets changes.

Production review question

If a team adopts WebSockets, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track websockets health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For WebSockets, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.