WebSockets & Real-Time: Connections, Scaling & Protocols

WebSockets & Real-time Communication

Why Engineers Care About This

WebSockets enable bidirectional, real-time communication between clients and servers. Unlike HTTP (request/response), WebSockets maintain persistent connections, allowing servers to push data to clients instantly. This enables real-time features (chat, notifications, live updates), but adds complexity—connection management, scaling, and message protocols.

When you need real-time updates, or polling creates too much overhead, or you need bidirectional communication, you're hitting problems that WebSockets solve. These problems compound. Polling (checking for updates every few seconds) wastes bandwidth and creates latency. Long polling (keeping HTTP requests open) works but is inefficient. WebSockets provide true real-time communication, but require careful connection management and scaling strategies.

In interviews, when someone asks "How would you implement real-time updates?", they're really asking: "Do you understand WebSockets? Do you know when to use WebSockets vs polling vs Server-Sent Events? Do you understand scaling challenges?" Most engineers don't. They use polling for everything (simple but inefficient) or WebSockets without understanding trade-offs (complex but sometimes unnecessary).

Core Intuitions You Must Build

• WebSockets are persistent connections, not just "HTTP with upgrades." WebSockets start as HTTP connections (handshake), then upgrade to WebSocket protocol. Once upgraded, the connection stays open, allowing bidirectional communication. This is different from HTTP (request/response, connection closes). WebSocket connections are stateful—servers must track connections, handle disconnections, and manage connection lifecycle.

• WebSockets enable server push, but require connection management. With HTTP, clients poll for updates (inefficient). With WebSockets, servers push updates to clients (efficient). But WebSocket connections must be managed—track active connections, handle disconnections, implement heartbeat (ping/pong) to detect dead connections, and clean up resources. Connection management is the hard part of WebSockets.

• Scaling WebSockets requires sticky sessions or message broadcasting. WebSocket connections are stateful—each connection is tied to a specific server. With multiple servers, you need sticky sessions (route same client to same server) or message broadcasting (send messages to all servers, forward to clients). Sticky sessions limit load balancing flexibility. Message broadcasting requires infrastructure (Redis pub/sub, message queues). Choose based on your requirements.

• WebSockets vs Server-Sent Events vs polling is about trade-offs. WebSockets: bidirectional, persistent, complex. Server-Sent Events (SSE): server-to-client only, persistent, simpler. Polling: simple, but inefficient. Use WebSockets for bidirectional real-time (chat, gaming). Use SSE for server-to-client updates (notifications, live feeds). Use polling for infrequent updates or when simplicity matters more than efficiency.

• Message protocols matter for WebSockets. WebSockets send raw bytes—you must define a message protocol (JSON, MessagePack, Protocol Buffers). Choose based on your needs—JSON is human-readable but larger, MessagePack is binary and smaller, Protocol Buffers are structured and efficient. Also, handle message framing (how to split messages) and error handling (malformed messages).

• Connection limits and resource management are critical. WebSocket connections consume server resources (memory, file descriptors). Each connection requires memory for buffers and state. Servers have connection limits (OS file descriptor limits, server configuration). Design systems that handle connection limits gracefully—reject new connections when at capacity, or implement connection pooling/queuing. Also, monitor connection counts and resource usage.

Subtopics (Taught Through Real Scenarios)

WebSocket Connection Lifecycle

What people usually get wrong:

Engineers often think "WebSockets just work—open connection, send messages." But WebSocket connections have a lifecycle: handshake (HTTP upgrade), open (connection established), message (data exchange), close (connection closed). Each stage requires handling—handshake validation, connection tracking, message parsing, cleanup on close. Also, connections can fail (network issues, server crashes), requiring reconnection logic. Don't assume connections stay open forever—implement reconnection and error handling.

How this breaks systems in the real world:

A service used WebSockets for real-time updates but didn't implement heartbeat (ping/pong). Dead connections (network issues, client crashes) weren't detected. The service tracked these connections as "active," sending messages to dead connections and wasting resources. Over time, dead connections accumulated, consuming memory and file descriptors. The service ran out of resources and crashed. The fix? Implement heartbeat—send ping messages periodically, close connections that don't respond. But the real lesson is: WebSocket connections can die silently. Implement heartbeat to detect and clean up dead connections.

What interviewers are really listening for:

They want to hear you talk about WebSocket lifecycle, connection management, and heartbeat. Junior engineers say "WebSockets just work." Senior engineers say "WebSocket connections have a lifecycle (handshake, open, message, close), require connection tracking and cleanup, and need heartbeat to detect dead connections." They're testing whether you understand that WebSocket connections require active management.

Scaling WebSockets

What people usually get wrong:

Engineers often think "just add more servers" for WebSocket scaling. But WebSocket connections are stateful—each connection is tied to a specific server. With multiple servers, you need sticky sessions (route same client to same server) or message broadcasting (send messages to all servers). Sticky sessions limit load balancing (can't move connections between servers). Message broadcasting requires infrastructure (Redis pub/sub, message queues). Scaling WebSockets is harder than scaling HTTP.

How this breaks systems in the real world:

A service had 3 servers handling WebSocket connections. A user connected to server 1. When server 1 sent a message to the user, it worked. But when server 2 needed to send a message to the same user, it couldn't (user is connected to server 1). Messages were lost or delayed. The fix? Use message broadcasting—when server 2 needs to send a message, publish it to Redis pub/sub, all servers receive it, server 1 forwards it to the user. But the real lesson is: WebSocket scaling requires infrastructure. Sticky sessions or message broadcasting are necessary for multi-server deployments.

What interviewers are really listening for:

They want to hear you talk about WebSocket scaling challenges, sticky sessions, and message broadcasting. Junior engineers say "just add more servers." Senior engineers say "WebSocket connections are stateful, requiring sticky sessions or message broadcasting for multi-server deployments—sticky sessions limit load balancing, message broadcasting requires infrastructure (Redis pub/sub)." They're testing whether you understand that scaling WebSockets is more complex than scaling HTTP.

WebSockets vs Server-Sent Events vs Polling

What people usually get wrong:

Engineers often use WebSockets for everything, or polling for everything. But different real-time technologies solve different problems. WebSockets: bidirectional, persistent, complex. Server-Sent Events (SSE): server-to-client only, persistent, simpler. Polling: simple, but inefficient. Use WebSockets for bidirectional real-time (chat, gaming). Use SSE for server-to-client updates (notifications, live feeds). Use polling for infrequent updates or when simplicity matters.

How this breaks systems in the real world:

A service used polling for real-time notifications (check every 5 seconds). This worked but wasted bandwidth (most polls returned no updates) and created latency (up to 5 seconds delay). During high activity, polling increased server load. The fix? Use Server-Sent Events (SSE) for server-to-client updates—servers push notifications immediately, no polling needed. But the real lesson is: choose the right real-time technology. WebSockets for bidirectional, SSE for server-to-client, polling for infrequent updates.

What interviewers are really listening for:

They want to hear you talk about different real-time technologies and when to use each. Junior engineers say "just use WebSockets" or "just use polling." Senior engineers say "WebSockets for bidirectional real-time, SSE for server-to-client updates, polling for infrequent updates—choose based on requirements." They're testing whether you understand that different real-time technologies solve different problems.

Message Protocols and Framing

What people usually get wrong:

Engineers often send raw strings over WebSockets without defining a message protocol. This works for simple cases, but breaks for complex messages (binary data, multiple message types, error handling). Define a message protocol (JSON with message type, MessagePack for binary, Protocol Buffers for structured data). Also, handle message framing (how to split messages) and error handling (malformed messages). Don't assume messages are always valid—validate and handle errors.

How this breaks systems in the real world:

A service sent JSON strings over WebSockets without message framing. Messages were concatenated (multiple JSON objects in one WebSocket frame), causing parsing errors. The service tried to parse concatenated JSON, failed, and dropped messages. The fix? Use message framing—send one JSON object per WebSocket message, or use a delimiter/prefix to separate messages. But the real lesson is: WebSocket messages are raw bytes. Define a message protocol and handle framing.

What interviewers are really listening for:

They want to hear you talk about message protocols, framing, and error handling. Junior engineers say "just send JSON strings." Senior engineers say "define a message protocol (JSON, MessagePack, Protocol Buffers), handle message framing (one message per frame or delimiters), and validate messages to handle errors." They're testing whether you understand that WebSocket messages require protocol design.

---

• WebSockets enable bidirectional real-time communication but require connection management
• Connection lifecycle must be managed—handshake, open, message, close, with heartbeat for dead connection detection
• Scaling WebSockets requires sticky sessions or message broadcasting—connections are stateful
• Choose the right real-time technology—WebSockets for bidirectional, SSE for server-to-client, polling for infrequent updates
• Message protocols matter—define protocols (JSON, MessagePack, Protocol Buffers) and handle framing
• Connection limits and resource management are critical—monitor connections and handle limits gracefully
• WebSockets are stateful—different from HTTP's stateless request/response model

---

• API Design - Designing real-time APIs
• Message Queues - Using message queues for WebSocket message broadcasting
• System Design - Scaling real-time systems