7. Long Polling vs SSE vs Web Socket

---

Think of a cricket score app 🏏.

“How does the server push real-time updates to clients?“

1️⃣ Polling

The client repeatedly asks: > “Any new updates?” at a fixed interval.

Flow

Client                      Server
 
Request --------------->
 
               Current Score = 100
 
<--------------- Response
 
(wait 5 sec)
 
Request --------------->
 
               Current Score = 100
 
<--------------- Response
 
(wait 5 sec)
 
Request --------------->
 
               Current Score = 120
 
<--------------- Response

Example

Client calls: GET /score every 5 seconds.

Pros

• Simple
• Easy to implement
• Works everywhere

Cons

• Lots of unnecessary requests
• High server load
• Updates are delayed

If polling interval = 5 sec Server updated at 10:01 - Client sees at 10:05 Latency can be up to polling interval.

System design Use Cases

• Monitoring pages - Dashboard refresh every minute

Not suitable for chat apps

---

2️⃣ Long Polling

Instead of immediately responding: Server waits until new data arrives.

Pros

• Almost real-time
• Atleast better then Polling

Cons

• Connection repeatedly opens/closes
• Scalability - Doesn’t scale as well for millions of users - creates http overhead

System design Use Cases

• Notification systems
• Before WebSockets became common

---

3️⃣ SSE (Server-Sent Events)

SSE keeps one HTTP connection open. Server continuously pushes updates.

Flow

Client ---------------------> Connect
 
Client <--------------------- Event
 
Client <--------------------- Event
 
Client <--------------------- Event
 
Client <--------------------- Event

Connection remains open.

Example

Browser:

const eventSource =
    new EventSource("/events");

Server:

data: Score = 100
 
data: Score = 120
 
data: Score = 150

Characteristics

Feature	SSE
Direction	Server → Client
Protocol	HTTP
Persistent Connection	Yes
Auto Reconnect	Yes
Browser Support	Excellent

Pros

• Simpler than WebSockets
• Uses HTTP
• Automatic reconnection
• Great for live feeds

Cons

• One-way communication
• Client cannot push data through same connection

Interview Use Cases

• Stock prices
• Live sports score
• News feed
• Monitoring dashboard

---

4️⃣ WebSockets

WebSocket creates a persistent TCP connection.

After connection establishment:

Client <---------> Server

Both sides can send messages anytime.

---

Handshake

Starts as HTTP:

GET /chat
Upgrade: websocket

Server:

101 Switching Protocols

Now protocol becomes WebSocket.

---

Flow

Client  <=================> Server
 
         Chat Message
 
Client  <=================> Server
 
         Typing Event
 
Client  <=================> Server
 
         Read Receipt

Full duplex communication.

---

Characteristics

Feature	WebSocket
Direction	Two-way
Persistent	Yes
Real-time	Yes
Protocol Upgrade	Yes

---

Pros

• Lowest latency
• Full duplex
• Efficient
• Ideal for real-time apps

Cons

• More complex
• Stateful connections
• Load balancing becomes harder

---

Interview Use Cases

• Chat applications
• WhatsApp
• Slack
• Multiplayer games
• Trading platforms
• Collaborative editors

---

Quick Comparison

Feature	Polling	Long Polling	SSE	WebSocket
Real-time	❌	⚠️ Almost	✅	✅
Persistent Connection	❌	⚠️ Temporary	✅	✅
Direction	Client → Server	Client → Server	Server → Client	Bidirectional
HTTP Based	✅	✅	✅	Starts with HTTP
Server Push	❌	⚠️ Sort of	✅	✅
Complexity	Low	Medium	Medium	High
Scalability	Poor	Better	Good	Best for realtime

---

Easy Interview Rule

If interviewer asks:

User refreshes every minute

➡️ Polling

Notification service

➡️ Long Polling or SSE

Live cricket score

➡️ SSE

Reason:

• Server pushes updates
• Client rarely sends data
• Simpler than WebSocket

---

WhatsApp / Slack

➡️ WebSocket

Reason:

• User sends and receives messages continuously
• Bidirectional communication required

---