When developers need real-time updates, the first instinct is usually simple:
“Let’s just ask the server every few seconds.”
This approach is called polling.
At first, it works fine.
But as your application grows, problems start appearing:
- Too many unnecessary requests
- Increased server load
- Delayed updates
- Wasted bandwidth
And suddenly, something that looked simple becomes inefficient.
🚨 The Problem with Polling
Let’s say you're building a food delivery tracker.
Your frontend keeps asking:
Client → “Any update?”
Server → “No”
Client → “Any update?”
Server → “No”
Client → “Any update?”
Server → “Order is out for delivery”
This continues every few seconds.
Even when there is no update, the request still happens.
Now imagine:
- 10,000 users
- Each sending requests every 5 seconds
That’s 120,000 requests per minute — most of them useless.
💡 What We Actually Want
Instead of repeatedly asking:
“Any update?”
We want the browser to say:
“Tell me when there is an update.”
This flips the model completely.
🔁 Enter Server-Sent Events (SSE)
Server-Sent Events (SSE) allow the server to push updates to the client over a single, long-lived HTTP connection.
Instead of:
Client → request → response → close
We get:
Client → open connection
Server → send updates whenever they happen
🧠 Mental Model
Think of SSE like a live news ticker.
Once you tune in, updates keep flowing:
- Order received
- Cooking started
- Out for delivery
- Delivered
No refreshing. No repeated requests.
⚙️ How Is This Different from Normal HTTP?
In a typical API:
- The client sends a request
- The server sends a response
- The connection closes
With SSE:
- The client sends a request
- The server keeps the connection open
- The server sends data continuously over time
🧩 Where SSE Fits
SSE is perfect when:
- Updates come from server → client
- You don’t need the client to send continuous messages back
Common use cases:
- Notifications
- Live sports scores
- Stock price updates
- Activity feeds
- AI streaming responses
⚠️ Important Constraint
SSE is one-way communication:
Server → Client ✅
Client → Server ❌ (not continuous)
If your system requires two-way communication (like chat), you would use WebSocket instead.
🚀 What’s Next
In the next article, we’ll break down:
👉 How SSE actually works at the protocol level
👉 How the browser receives and processes events
This is where things get interesting.
Top comments (0)