WebSocket
Cheat Sheet
Prime Use Case
Use when you require low-latency, bidirectional, and persistent communication between a client and a server, such as in collaborative editing, real-time trading, or multiplayer gaming.
Critical Tradeoffs
- Stateful server-side management vs. Stateless HTTP scalability
- Reduced per-message overhead vs. Increased connection establishment cost
- Real-time delivery vs. Complexity in load balancing and failover
Killer Senior Insight
WebSockets shift the scaling bottleneck from CPU and Network Bandwidth to Memory and Open File Descriptors; a server's capacity is defined by how many concurrent 'idle' connections it can hold in RAM, not how many requests per second it can process.
Recognition
Common Interview Phrases
Common Scenarios
- Instant Messaging and Chat Applications
- Live Sports Tickers or Financial Trading Platforms
- Collaborative Tools (e.g., Google Docs, Figma)
- Real-time Multiplayer Gaming
- Live Dashboard Monitoring
Anti-patterns to Avoid
- Using WebSockets for simple CRUD operations that happen infrequently.
- Implementing WebSockets for one-way server-to-client updates where SSE (Server-Sent Events) would suffice.
- Using WebSockets for static content delivery or large file transfers.
The Problem
The Fundamental Issue
Eliminating the overhead and latency of the HTTP request-response cycle for continuous data exchange.
What breaks without it
High latency due to TCP/TLS handshake overhead for every request.
Server resources exhausted by constant 'Short Polling' requests.
Client battery drain and network congestion from frequent empty polls.
Why alternatives fail
Short Polling: Too much lag and massive overhead from repeated headers.
Long Polling: Holds server threads hostage and still requires a new connection for every message sent.
HTTP/1.1: Strictly unidirectional and synchronous (Head-of-Line blocking).
Mental Model
The Intuition
Think of HTTP like sending letters: you send one, wait for a reply, and the postman leaves. WebSockets are like a dedicated phone call: once the line is open, both parties can speak whenever they want without redialing, until someone hangs up.
Key Mechanics
HTTP Upgrade Handshake: Client sends 'Upgrade: websocket' header.
101 Switching Protocols: Server acknowledges and switches from HTTP to binary framing.
Framing: Data is sent in small binary frames rather than heavy text-based HTTP packets.
Keep-Alive/Heartbeats: Ping/Pong frames used to ensure the connection hasn't silently dropped.
Framework
When it's the best choice
- Bidirectional communication is a core requirement.
- Message frequency is high (multiple messages per second).
- Low latency is critical for user experience (e.g., cursor positions).
When to avoid
- The application must work over highly restrictive corporate firewalls that block non-standard ports or protocols.
- The client is extremely resource-constrained and cannot maintain a persistent socket.
- The data updates are infrequent (e.g., once every few minutes).
Fast Heuristics
Tradeoffs
Strengths
- Extremely low overhead (2-14 bytes per frame vs. kilobytes for HTTP).
- Full-duplex (simultaneous) communication.
- Persistent connection reduces latency by skipping handshakes.
Weaknesses
- Stateful: Servers must track every connection, making horizontal scaling harder.
- Load Balancing: Requires 'Sticky Sessions' or L4 (TCP) load balancing; L7 balancers must support the Upgrade header.
- Connection Management: Must handle 'Zombie' connections and complex reconnection logic on the client.
Alternatives
When it wins
When you only need to push data from server to client (e.g., news feeds).
Key Difference
Unidirectional, works over standard HTTP, handles reconnection automatically.
When it wins
When you need even lower latency and can use HTTP/3 (UDP-based).
Key Difference
Supports multiple streams and unreliable delivery (like UDP), avoiding TCP Head-of-Line blocking.
When it wins
As a fallback for very old browsers or environments that block WebSockets.
Key Difference
Emulates persistence by holding an HTTP request open until data is available.
Execution
Must-hit talking points
- Mention the 'Handshake' process and the 101 Switching Protocols status code.
- Discuss scaling using a 'Pub/Sub' backplane (like Redis or NATS) to broadcast messages across multiple server nodes.
- Explain the importance of 'Heartbeats' (Ping/Pong) to detect dead connections through intermediate proxies.
- Address the 'C10k' and 'C10m' problems regarding memory per connection.
Anticipate follow-ups
- Q:How do you handle load balancing for WebSockets? (Answer: L4 vs L7, sticky sessions, or consistent hashing).
- Q:What happens if a user moves from Wi-Fi to 5G? (Answer: Connection drop, client-side retry with exponential backoff).
- Q:How do you secure WebSockets? (Answer: WSS/TLS, token-based auth in the initial handshake URL or headers).
Red Flags
Assuming WebSockets automatically scale like REST.
Why it fails: REST is stateless; any server can handle any request. WebSockets are stateful; if Client A is on Server 1 and Client B is on Server 2, they can't talk without a shared message broker.
Neglecting the 'Zombie Connection' problem.
Why it fails: TCP connections can 'half-close' where one side thinks it's open but the other doesn't. Without application-level heartbeats, you leak memory and file descriptors.
Using WebSockets for everything to 'be modern'.
Why it fails: It introduces unnecessary complexity in caching, testing, and monitoring compared to standard HTTP.