Real-time Communication Techniques

The Limits of Traditional HTTP

The standard HTTP protocol, which has been the workhorse of our discussions so far, operates on a strict request-response basis. The client always initiates the conversation, the server responds, and the connection typically closes. This poses a fundamental problem for real-time features: how can a server notify a client about a new message or an updated stock price at the moment it happens?

The most naive solution is short polling, where the client repeatedly asks the server "Anything new?" at a fixed interval (e.g., every 2 seconds).

As you can imagine, this is incredibly inefficient. Most requests will return empty, but each one carries the overhead of HTTP headers and a new TCP connection. At scale, this leads to a massive waste of server resources and network bandwidth. To solve this, engineers developed several more sophisticated patterns.

Let's start by reading a brief overview of the problem and the four main approaches to solve it.

Simulating Real-Time: Long Polling

Long polling is a clever enhancement of short polling. Instead of responding immediately, the server holds the client's request open until it actually has new data to send.

Here’s the flow:

1. The client sends an HTTP request to the server.
2. The server doesn't respond right away if there's no new data. It keeps the connection open, waiting. This is often called a "hanging GET".
3. When new data becomes available, the server sends it as the response to the open request, and the connection is closed.
4. The client immediately makes a new request to the server, and the cycle repeats.

This pattern drastically reduces the number of empty responses and lowers latency, as data is sent almost as soon as it's available. The following video provides a concise explanation.

Long polling's main advantage is its simplicity and compatibility. It's built entirely on standard HTTP, so it works everywhere without needing special server configurations or worrying about restrictive firewalls. However, it's not a truly persistent connection. It still incurs the overhead of opening a new connection for every event, and holding many connections open can be resource-intensive on the server.

Persistent Connections: A More Modern Approach

While long polling is a useful "hack," modern applications often turn to protocols designed specifically for persistent connections. These methods establish a single, long-lived connection and amortize the setup cost over many messages.

Server-Sent Events (SSE)

Server-Sent Events provide a unidirectional, persistent connection for the server to push data to the client.

Here's how it works:

1. The client makes a single HTTP request to an endpoint, specifying it wants to receive an event stream (Accept: text/event-stream).
2. The server responds with a special content type and keeps the connection open indefinitely.
3. Whenever the server has a new event, it writes it to the response stream.

This is much more efficient than long polling for frequent updates, as the connection is established only once. A standout feature of SSE is that the browser's EventSource API handles connection management automatically. If the connection drops, the browser will automatically try to reconnect. It even sends the ID of the last event it received, allowing the server to replay any missed messages.

Use Cases: SSE is ideal for features like news feeds, stock tickers, streaming AI responses (like ChatGPT), or live build logs (like GitHub Actions), where the data flow is primarily from server to client.

Key Limitation: SSE is strictly one-way. If the client needs to send data back to the server, it must do so using a separate, standard HTTP request.

WebSockets

WebSockets provide a bidirectional, full-duplex communication channel over a single TCP connection. This is the most powerful and lowest-latency option.

The process starts with an "upgrade handshake":

1. The client sends a standard HTTP request with an Upgrade: websocket header.
2. If the server agrees, it responds with a 101 Switching Protocols status code.
3. The HTTP connection is then replaced by a raw TCP connection, over which both the client and server can send data at any time.

After the handshake, the communication is no longer HTTP-based. Messages are sent as "frames" with very little overhead (as little as 2 bytes per frame), making it extremely efficient for high-frequency updates.

Use Cases: WebSockets are essential for interactive applications like chat (Slack), collaborative editing (Figma, Google Docs), and multiplayer online games, where both the client and server need to send messages in real time.

Key Limitations: WebSockets are more complex to implement and scale. They are not plain HTTP, so they can be blocked by older proxies and firewalls. Also, unlike SSE, they do not have a built-in automatic reconnection mechanism; you must implement that logic yourself or use a library.

Comparison and Decision Framework

Now that you understand the mechanics of each pattern, the crucial interview skill is knowing when to use which. The choice almost always hinges on one primary question: Do you need bidirectional communication?

Let's read a detailed comparison and a practical decision guide.

To frame this in a direct interview context, let's look at how you would apply this decision-making process to a typical system design problem.

Conclusion

You now have a solid framework for analyzing and choosing between the primary real-time communication patterns used in modern backend systems. Being able to discuss not just what they are, but why you'd choose one over the other—considering factors like directionality, latency, efficiency, and operational complexity—is what separates a good interview candidate from a great one.

Key Takeaways:

• The Core Problem: Standard HTTP is a client-initiated, request-response protocol, making it unsuitable for server-pushed, real-time updates.
• Long Polling: A simple, compatible HTTP-based "hack" that simulates real-time pushes. Best used as a fallback or in environments with restrictive firewalls.
• Server-Sent Events (SSE): The ideal choice for unidirectional server-to-client communication. It's efficient, built on HTTP, and features automatic reconnection. Think notifications, live feeds, and data streams.
• WebSockets: The go-to solution for true bidirectional, low-latency communication. Essential for chat, collaborative apps, and gaming, but brings higher implementation and scaling complexity.
• The Decision Framework: Always start by asking if communication needs to be bidirectional. If yes, choose WebSockets. If no, SSE is almost always the simpler, more robust choice.

This lesson concludes our module on API Design and Communication. We've journeyed from the basics of HTTP and REST, through pagination and error handling, to these advanced real-time patterns. In our next lesson, we will begin a new module, "Advanced Database Engineering," by diving deep into how databases use B-tree and hash indexes to execute queries efficiently.