WebSocket VS Polling VS SSE

Source: Dev.to

The Classic Request‑Response Model (and Its Limitations)

How Standard Web Apps Work

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

This cycle is simple and efficient for most applications.

Key problem: once the response is sent, the server cannot push fresh data to the client unless the client asks again.

Example: A Stock Market App

• Clients A, B, C connect and request current stock prices.
• The server responds and the connection closes.
• Later, prices change on the server, but clients A, B, C still have stale data.

How does the server tell clients that data has changed?

Solution 1: WebSockets

WebSockets keep a persistent full‑duplex connection open between client and server.

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 to communicate 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‑time updates
• ✅ Low latency
• ✅ Full duplex (two‑way communication)

Cons of WebSockets

• ❌ Hard to scale – it’s stateful (the server must remember every connected client)
• ❌ Horizontal scaling becomes expensive with millions of connections
• ❌ Servers must synchronize updates among themselves in clustered environments

Solution 2: Polling

Polling is the simplest alternative to WebSockets.

What Is Polling?

The client repeatedly asks the server for new data:

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

Simple Polling Example

If the client checks every 2 seconds:

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

If new data appears at 3.5 s, the client receives it at the next poll (4 s).
The maximum delay equals the poll interval.

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
• ❌ Wastes requests when no new data is available
• ❌ Frequent polling can add network load

Solution 3: Long Polling

Long polling is an optimized form of polling.

What Is Long Polling?

The server holds the request open until:

• New data arrives, or
• A timeout expires

Then it responds with the data in a single shot.

Example: Long Polling for 5 Seconds

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

If updates come within 5 s:
  Server → Client: Latest updates
  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

• ❌ Holds server resources while waiting
• ❌ Not as instant as WebSockets
• ❌ Server must manage held requests

Comparing the Approaches

Real‑World Considerations

Do You Always Need Full Real‑Time?

Not necessarily. In a stock‑chart app you might only need fresh price updates, while buying/selling can still use regular POST API routes. In such cases:

• WebSockets may be overkill.
• Polling or long polling can be perfectly adequate.

Why Polling Works Well with Load Balancers

When scaling with many backend servers behind a load balancer:

• Polling requests are distributed across servers.
• No single server holds a persistent connection.
• If a server fails, the next poll is routed to another healthy server.

Final Thoughts

Real‑time systems are 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 and evolve as needed

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