Kader Khan

Posted on Jan 3

WebSocket VS Polling VS SSE

#architecture #networking #webdev

📌 The Classic Request-Response Model (and Its Limitations)

How Standard Web Apps Work

In a typical web app:

A client (browser/app) sends a request to the server.
The server processes it (DB access, computation, etc.).
The server sends back a response.
The connection closes.

This cycle is simple and efficient for most applications.

👉 But here’s the key problem:

Once the response is done, the server cannot send fresh data to the client unless the client asks again.

Example: A Stock Market App

Suppose you have a simple stock application:

🧑‍💻 Clients A, B, C connect and request current stock prices.
📡 The server responds — and bam! connection closes.
📉 Later, prices change on the server.
But clients A, B, C still only have old (stale) data.

This becomes a real-time problem:
👉 How does the server tell clients that data has changed?

🚀 Solution 1: WebSockets

WebSockets let you keep a persistent full-duplex connection open between clients and servers.

What Does This Mean?

Instead of:

Client → Server → Response → Connection closes

WebSockets keep the connection open:

Client ↔ Server ↔ Client ↔ Server

This allows:

The server to push updates anytime.
The client to send data anytime.
Both sides talk without closing the connection.

How It Works (Simple Diagram)

Client                         Server
  | — WebSocket handshake →     |
  |                             |
  | ← Accept & open channel —   |
  |                             |
  | — Updates can flow both →   |
  |                             |

Once the connection is open, either side can send data.

Pros of WebSockets

✅ Real real-time updates
✅ Low latency
✅ Full duplex (two-way communication)

Cons of WebSockets

❌ Hard to scale — it’s stateful (server must remember every connected client)
❌ If you have millions of connections, scaling horizontally becomes expensive
❌ Servers must synchronize updates among themselves in clustered systems

🚀 Solution 2: Polling

Polling is the simplest alternative to WebSockets.

What Is Polling?

Instead of keeping a connection alive, the client asks the server again and again:

Client: “Any new updates?”
Server: “Nope.”
Client: “Any new updates?”
Server: “Yes — here you go!”

Simple Polling Example

Let’s say the client checks every 2 seconds:

0s → “Give me new data”
2s → “Give me new data”
4s → “Give me new data”
…

If new data appears at 3.5s, the client will only get it at the next poll (4s).

👉 That means the maximum delay is equal to your poll interval — 2 seconds in this example.

Pros of Polling

✅ Easy to implement
✅ Works with load balancers and many servers
✅ Stateless — each request is independent

Cons of Polling

❌ Not truly real-time
❌ Can waste requests if no new data
❌ Frequent polling may still add network load

🚀 Solution 3: Long Polling

Long polling is an optimized form of polling.

What Is Long Polling?

Instead of responding immediately, the server holds the request open until:

New data arrives, or
A timeout expires

Then it responds with data in one shot.

Example: Long Polling for 5 Seconds

Client → Server: “Any updates?”  
Server: Hold request for 5 seconds

If updates come within 5s:
  Server → Client: Latest updates
Then client immediately re-requests.

Pros of Long Polling

✅ Fewer requests than short polling
✅ More “real-time” feel than simple polling
✅ Still stateless

Cons of Long Polling

❌ Can still hold server resources
❌ Not as instant as WebSockets
❌ Server must manage held requests

📊 Comparing the Approaches

Technique	Real-Time	Scalability	Server Load	Complexity
Polling	Moderate (delayed)	🔥 Easy	🔥 Medium	🟢 Easy
Long Polling	Good	🔥 Good	🔥 Medium	🟡 Moderate
WebSockets	Excellent	🔻 Hard	🔻 High	🟡 Moderate

🧠 Real-World Considerations

Do You Always Need Full Real-Time?

Not always.

For example, in a stock chart app:

You might only need fresh price updates, not two-way communication.
Buying/selling can still happen via regular POST API routes.

That means:

WebSockets might be overkill.
Polling or long polling might be perfectly fine.

Why Polling Works Well with Load Balancers

When you scale with many backend servers and a load balancer:

Polling requests get distributed across servers,
You avoid being tied to one server connection,
If a server goes down, your next poll goes to another healthy server.

🏁 My Final Thoughts

Real-time systems aren’t magic — they’re about choosing the right tool for the job:

🔹 Need instant push updates? → WebSockets
🔹 Need lightweight, scalable updates? → Polling / Long Polling
🔹 Want a mix of both? → Start with polling, evolve as needed

Every choice has trade-offs. Understanding the fundamental communication patterns helps you make the best architectural decision — and prevents unnecessary complexity early on.

DEV Community