Real-Time Web: Polling, SSE, and WebSockets

---

1. The Core Problem: The Web is "Stateless"

The internet was originally built to be boring. In the standard HTTP model, communication is always initiated by the client. You ask for a page (GET /home), the server delivers it, and then the server immediately "hangs up." The connection is closed. The server forgets who you are.

But modern users expect Real-Time experiences:

• Uber drivers moving on a map in real-time.

• Slack messages appearing without refreshing.

• Stock prices ticking millisecond-by-millisecond.

To achieve this, we have to "cheat" the standard HTTP model. There are three primary architectural patterns to solve this problem: Polling, Server-Sent Events (SSE), and WebSockets.

Choosing the wrong one can lead to server crashes, high latency, or rapid battery drain for your users.

---

2. Polling: The "Are We There Yet?" Approach

Polling is the oldest and simplest technique. The client simply asks the server for updates on a fixed interval.

The Analogy: Imagine a child in the backseat of a car asking, "Are we there yet?" every 5 seconds. Most of the time, the answer is "No."

Short Polling vs. Long Polling

• Short Polling: The client sends a request every X seconds (e.g., every 2 seconds). This is wasteful.

• Long Polling: The client sends a request, and the server holds the connection open (hangs) until it actually has new data or a timeout occurs.

Pros

• Simplicity: Easiest to implement. Works with any backend (PHP, Python, Node, Java).

• Robustness: Works over standard HTTP, so it never gets blocked by corporate firewalls or proxies.

• Auto-Recovery: If the connection fails, the next poll just happens automatically.

Cons

• Latency: There is always a delay between the data changing and the next poll.

• Server Load: Thousands of clients polling creates massive "header overhead" (cookies, auth headers) for zero data.

• Wasted Resources: In Long Polling, holding thousands of open threads can exhaust server memory.

Use Cases

• Dashboard Refresh: Updating a sales dashboard every 5 minutes.

• Long-Running Tasks: Checking if a PDF export or video rendering job is finished.

• MVP / Prototypes: When you need "kind of" real-time but don't have time to build a complex socket architecture.

---

3. Server-Sent Events (SSE): The "Radio Station"

Server-Sent Events (SSE) is often the "Goldilocks" solution—not as heavy as WebSockets, but faster than polling. It allows the server to push data to the client over a single, long-lived HTTP connection.

The Analogy: It is like listening to the radio. The station (Server) broadcasts to you, but you cannot speak back to the station over the radio waves.

How It Works

1. The client opens a connection with the header Accept: text/event-stream.

2. The server keeps the HTTP connection open.

3. The server pushes text-based messages down the wire whenever an event occurs.

Pros

• Built-in Reconnection: The browser (via EventSource API) automatically reconnects if the internet drops. No extra code needed.

• Lightweight: Uses standard HTTP. Easier to debug in the "Network" tab than WebSockets.

• Firewall Friendly: Since it's just HTTP, it passes through almost all firewalls.

Cons

• Uni-Directional: The server can send to the client, but the client cannot send data back over the same connection.

• Text Only: Designed for text (UTF-8). Sending binary data (images/files) is inefficient (requires Base64 encoding).

• Connection Limits: Browsers (Chrome/Firefox) limit the number of open SSE connections to ~6 per domain (HTTP/1.1 issue).

Use Cases

• Live Feeds: Stock tickers, Crypto prices, News feeds.

• Notifications: "You have a new like" or "Order shipped" alerts.

• System Logs: Streaming server logs to a dashboard.

---

4. WebSockets: The "Phone Call"

WebSockets are the gold standard for truly interactive, bi-directional applications. A WebSocket starts as a normal HTTP request but performs a specialized "Handshake" to upgrade the protocol from HTTP to TCP.

The Analogy: A phone call. Once the line is open, both parties can talk over each other, simultaneously, as fast as possible.

How It Works

1. Handshake: Client sends Upgrade: websocket.

2. Persistence: The connection remains a raw TCP socket.

3. Frames: Data is sent in tiny, lightweight binary frames.

Pros

• Full Duplex: Bi-directional. Client and Server can talk simultaneously.

• Low Latency: Lowest possible latency on the web. No HTTP header overhead after the handshake.

• Efficiency: Great for high-frequency messages (e.g., 60 updates per second).

Cons

• Complexity: Requires a specialized backend. You must manage connection state (Heartbeats, Ping/Pong).

• No Auto-Reconnect: If the Wi-Fi drops, the connection dies. You must write code to detect and reconnect manually.

• Firewalls: Aggressive corporate proxies sometimes block non-standard HTTP traffic.

• Scaling Difficulty: WebSockets are stateful. You need a Message Broker (like Redis) to scale across multiple servers.

🎯 Use Cases

• Chat Apps: WhatsApp, Slack, Discord.

• Multiplayer Games: Agar.io, FPS browser games.

• Collaborative Tools: Google Docs, Figma (where multiple users edit at once).

• Location Tracking: Uber/Lyft driver tracking.

---

Summary

When designing your system, use this cheat sheet to choose the right technology.

Final Recommendation:

• Start with Polling if you are unsure. It’s easy to delete.

• Use SSE if you just need to update the UI with server data.

• Use WebSockets only if you need high-frequency, two-way interaction (like a game or chat).