Vishwark

Posted on Apr 2

🚀 Realtime Communication in Frontend (Polling vs WebSocket vs SSE)

#webdev #webocket #sse #frontend

Realtime features are everywhere today — chat apps, delivery tracking, payments, notifications.

But one mistake many developers make is:
👉 Using WebSocket for everything.

In real production systems, we use a mix of:

Polling
Server-Sent Events (SSE)
WebSocket

👉 The goal is simple: use the simplest solution that works reliably.

🧠 1. What is Realtime Communication?

Realtime means:
👉 Data updates without refreshing the page

But important point:
👉 Not all realtime needs to be instant

Some features can tolerate delay (2–5 seconds), and that changes the design.

🔁 2. Polling (Simple but Powerful)

What is Polling?

Client keeps asking server for updates:

setInterval(async () => {
  const res = await fetch("/status");
  const data = await res.json();
  console.log(data);
}, 5000);

When Polling Works Best

Use polling when:

Data changes slowly
You need high reliability
Simplicity is preferred

Real Example: Payment Status

Let’s understand this properly.

Flow:

User clicks “Pay”
Redirected to third-party gateway (Razorpay / Stripe)
Payment happens outside your app
Gateway sends webhook → your backend
Backend updates DB
Frontend checks status

Why Polling is Used Here

Frontend doesn’t control payment result
Gateway response timing is unpredictable
User may refresh or leave page

👉 So frontend polls backend:

setInterval(async () => {
  const res = await fetch("/payment/status?id=123");
  const data = await res.json();

  if (data.status === "success") {
    // stop polling
  }
}, 3000);

Why Not WebSocket or SSE?

Requires active connection
Not reliable across page refresh
Overkill for single status change

👉 Polling wins because it is simple and reliable

🔌 3. WebSocket (For True Realtime)

What is WebSocket?

Persistent connection
Two-way communication

👉 Both client and server can send data anytime

When to Use WebSocket

Chat apps
Live tracking (driver, delivery)
Multiplayer apps

Reconnection Problem (Real Issue)

Example:

User offline for 1 hour
1000 updates missed

Problems:

Missing data
Duplicate data
Wrong order

Real-world Solution Pattern

Use message IDs
Store last received ID
Fetch missing data after reconnect

fetch(`/messages?afterId=${lastId}`);

WhatsApp Example (Important)

Uses message IDs + ACK
Stores messages locally
Syncs missing messages after reconnect
Loads messages in chunks (avoid UI freeze)

👉 Large data is never pushed blindly

📡 4. Server-Sent Events (SSE)

What is SSE?

Server pushes data to client
One-way communication

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

 eventSource.onmessage = (event) => {
  console.log(event.data);
};

When to Use SSE

Notifications
Live dashboards
Activity feeds
Jenkins pipeline updates
Live cricket/sports score/commentary updates

Limitations

Client cannot send data
Not suitable for interactive systems

⚖️ 5. Polling vs SSE vs WebSocket

Feature	Polling	SSE	WebSocket
Direction	Client → Server	Server → Client	Two-way
Complexity	Low	Medium	High
Realtime	Low	Medium	High
Use case	Status	Notifications	Chat/Tracking

🧠 6. Real-world Scenarios (How to Choose)

This is where real engineering decisions happen.

🚗 Driver Tracking (Uber / Ola)

Flow:

Driver app sends location → Backend
Backend calculates ETA
Backend sends updates → User app

Why WebSocket is Commonly Used

Driver side needs to:

Send frequent location updates
Receive updates (route change, cancel, reassign)

👉 This becomes two-way communication → WebSocket fits well

Can We Avoid WebSocket?

Yes, there are alternatives.

Option 1: Driver → REST API (Polling/Push)

Driver sends location every few seconds via HTTP
Backend processes and stores data

Option 2: Backend → User via SSE

User receives updates via SSE

👉 This works if:

No real-time interaction required
Slight delay is acceptable

Trade-off

Approach	Pros	Cons
WebSocket	Low latency, real-time	More complex
REST + SSE	Simpler infra	Slight delay, more requests

👉 Real apps choose based on scale and need

🍔 Zomato / Swiggy

🟡 Order Status (Placed → Delivered)

Low frequency updates
Delay is acceptable

👉 Polling is usually used

Can SSE Work?

Yes, and some systems may use it.

Flow:

Backend updates DB
SSE pushes new status
Client updates UI

👉 But:

Needs persistent connection
More infra setup

👉 Polling is simpler and reliable

🟢 Delivery Tracking (Map Movement)

Flow:

Delivery partner → Backend (location updates)
Backend → User (location + ETA)

Common Assumption

👉 “User only needs data, so SSE is enough”

This is partially correct.

Real-world Consideration

Even user app may need to:

Cancel order
Change address
Trigger actions

👉 These go via REST APIs

Possible Architectures

Option 1 (Simpler)

Driver → REST (send location)
Backend → SSE (push updates to user)
User → REST (actions like cancel)

👉 Works well for moderate scale

Option 2 (Advanced / High Scale)

Driver ↔ Backend → WebSocket
User ↔ Backend → WebSocket

👉 Benefits:

Lower latency
Unified system
Easier event handling

Why Many Apps Still Use WebSocket

One consistent system
Handles all events (location, cancel, updates)
Better performance at scale

👉 Even if SSE + REST is possible, WebSocket simplifies architecture

🏗️ 7. Stateless vs Stateful Architecture (Very Important)

Understanding this helps you choose the right protocol.

Stateless (REST APIs)

Each request is independent
Server does not store connection state

Example:

GET /order/status

👉 Server responds and forgets

Pros

Easy to scale
Works with load balancers
Reliable

Cons

Not efficient for realtime
Requires repeated requests (polling)

Stateful (WebSocket)

Connection stays open
Server maintains session/connection state

👉 Server knows client is connected

Pros

Real-time communication
Low latency

Cons

Harder to scale
Needs connection management

SSE (Hybrid)

Uses HTTP (stateless)
But keeps connection open

👉 Semi-stateful

🌐 8. REST vs Realtime APIs

REST APIs

Request → Response
Stateless
Works well for CRUD operations

Realtime APIs (WebSocket / SSE)

Event-driven
Continuous data flow

When to Use What

REST → actions (create, update, cancel)
WebSocket/SSE → live updates

👉 Most apps use both together

🧠 Decision Framework

Ask these questions:

Do I need two-way communication?
👉 Yes → WebSocket
👉 No → SSE or Polling
How frequent are updates?
👉 Low → Polling
👉 Medium → SSE
👉 High → WebSocket
Do I need simplicity or performance?
👉 Simplicity → Polling
👉 Performance → WebSocket