Hey developers! š
Welcome back to our journey through communication patterns in distributed systems.
For years, the web operated on a simple principle:
Browser asks.
Server answers.
Connection closes.
This model worked perfectly when websites were mostly documents.
A user opened a page.
The browser requested data.
The server responded.
Everyone moved on.
But then the internet changed.
Businesses wanted live stock prices.
Operations teams wanted real-time monitoring dashboards.
Support agents wanted instant notifications.
Users expected applications to update the moment something happened.
The old request-response model suddenly felt too slow.
The challenge wasn't generating updates.
The challenge was delivering those updates immediately.
And that led engineers down an interesting path:
Request-Response
ā
Polling
ā
Long Polling
ā
Server-Sent Events (SSE)
SSE wasn't just another communication technique.
It was the web's attempt to become truly real-time while staying inside the familiar world of HTTP.
A Quick Recap: Why Long Polling Wasn't Enough
Long Polling was a major improvement over traditional Polling.
Instead of asking repeatedly:
Anything new?
the client said:
Tell me when something changes.
The server waited.
When an event occurred:
Server Responds
ā
Client Creates New Request
ā
Server Waits Again
Much more efficient.
But there was still a pattern hiding underneath.
Every update required:
Response
ā
Reconnect
ā
Wait Again
The browser was still responsible for repeatedly initiating communication.
Just less frequently.
Engineers started wondering:
What if the browser only connected once?
The Simple Question That Changed Everything
Imagine a support dashboard.
A stock market application.
An AI assistant.
A monitoring platform.
All of them share the same behavior:
Server Knows When Something Changes
So why does the client keep asking?
Instead of:
Client:
Anything new?
Server:
No.
What if the browser simply said:
I'm listening.
And stayed connected?
That idea became Server-Sent Events.
What Is Server-Sent Events (SSE)?
Server-Sent Events is a communication pattern where a browser opens a single HTTP connection and keeps it alive.
Instead of repeatedly requesting updates, the browser listens.
The server sends data whenever new information becomes available.
Browser
ā
ā Open Connection
ā¼
Server
ā
āāā Event
āāā Event
āāā Event
āāā Event
The browser becomes a subscriber.
The server becomes a publisher.
No polling loop.
No repeated requests.
No constant reconnecting after every update.
Think of SSE Like a News Subscription
Imagine subscribing to a news service.
Polling looks like this:
You:
Any news?
Publisher:
No.
You:
Any news?
Publisher:
No.
You:
Any news?
SSE looks like this:
You:
Send me news whenever it happens.
Publisher:
Understood.
Hours later:
Breaking News
ā
ā¼
Notification Delivered
You don't repeatedly check.
The publisher contacts you when something important occurs.
That's the core idea behind SSE.
What Actually Happens Under the Hood?
From the browser's perspective, opening an SSE connection is surprisingly simple.
const events = new EventSource("/events");
The browser sends a normal HTTP request.
The server responds with a special content type:
text/event-stream
Unlike a normal HTTP response, the connection remains open.
Instead of returning a complete response and closing:
Request
ā
Response
ā
Close
the server continuously streams events:
data: New Order Created
data: Payment Received
data: Shipment Dispatched
The browser receives events immediately.
The stream stays alive.
The connection remains open.
A Visual Mental Model
Long Polling
Request
ā
Wait
ā
Response
ā
Reconnect
ā
Wait Again
SSE
Connect Once
ā
Listen
ā
Event
ā
Event
ā
Event
ā
Still Listening
The difference seems small.
Architecturally, it's significant.
Real System Example: E-Commerce Dashboard
Imagine a large e-commerce platform.
Operations teams monitor incoming orders.
Without SSE:
Dashboard
ā
Poll Every 5 Seconds
ā
Check For Orders
A customer places an order.
The dashboard updates several seconds later.
With SSE:
Customer Places Order
ā
ā¼
Order Service
ā
ā¼
Notification Service
ā
ā¼
SSE Stream
ā
ā¼
Dashboard
The moment an order is created:
New Order Received
appears instantly.
To users:
The System Feels Alive
Real System Example: Monitoring Platforms
Modern monitoring tools display:
- CPU usage
- Memory usage
- Error rates
- Latency
- Active users
These metrics change constantly.
Polling every few seconds creates unnecessary traffic.
Instead:
Monitoring Agent
ā
ā¼
Metrics Service
ā
ā¼
Event Stream
ā
ā¼
SSE
ā
ā¼
Dashboard
As metrics change, updates appear immediately.
Operations teams gain near real-time visibility into system health.
Real System Example: AI Response Streaming
One of the most recognizable uses of SSE today is AI.
When you ask an AI assistant a question, the model doesn't generate an entire answer instantly.
It generates tokens gradually.
Without streaming:
Question
ā
Wait 10 Seconds
ā
Entire Response Appears
Users experience:
Silence
With SSE:
Question
ā
Short Wait
ā
Words Begin Appearing
ā
More Words
ā
More Words
The total generation time may be identical.
But the experience feels dramatically faster.
This reveals an important design principle:
Users experience latency differently than systems measure latency.
A ten-second delay feels slow.
A ten-second stream feels interactive.
SSE helps bridge that gap.
Why Product Teams Love SSE
Product teams rarely ask:
Is this protocol elegant?
They ask:
Does the product feel responsive?
Compare:
Click
ā
Wait
ā
Wait
ā
Wait
ā
Response
Versus:
Click
ā
Response Starts
ā
More Content
ā
More Content
The second experience feels significantly faster.
That often translates into:
- Better engagement
- Higher retention
- Increased trust
- Improved customer satisfaction
The implementation details are invisible.
The user experience isn't.
Why Developers Love SSE
One reason SSE became popular is its simplicity.
It works with existing HTTP infrastructure.
Browser
ā
HTTP
ā
Load Balancer
ā
Reverse Proxy
ā
Application Server
No entirely new protocol.
No custom client libraries.
No complicated connection management.
Developers also benefit from automatic reconnection.
If the connection drops:
Connection Lost
ā
ā¼
Browser Detects Failure
ā
ā¼
Automatic Reconnect
Many recovery scenarios are handled automatically.
Less code.
Fewer edge cases.
Simpler implementations.
Why Architects Choose SSE
A common question appears:
Why not just use WebSockets?
Because not every system needs two-way communication.
Consider:
Stock Market
ā
ā¼
Browser
Or:
Monitoring System
ā
ā¼
Dashboard
Or:
AI Model
ā
ā¼
User Interface
All of these follow:
Server
ā
Client
The server sends most of the information.
The client mostly listens.
SSE fits naturally.
One of the most important architecture lessons is:
The best solution isn't the most powerful one. It's the simplest one that satisfies the requirements.
For many one-way streaming systems, SSE is exactly that solution.
The Hidden Challenge
Every architectural improvement introduces a new bottleneck.
Polling created:
Too Many Requests
SSE dramatically reduces that problem.
But it introduces another:
Persistent Connections
Imagine:
500,000 Active Users
Polling might create:
Millions of Requests Per Minute
SSE creates:
500,000 Open Connections
The request problem improves.
Connection management becomes the new challenge.
Infrastructure teams start thinking about:
- Memory usage
- File descriptor limits
- Load balancer behavior
- Proxy timeouts
- Reconnection storms
- Horizontal scaling
An important lesson emerges:
Fewer Requests
ā
Less Work
The workload simply shifts.
SSE vs Long Polling
| Feature | Long Polling | SSE |
|---|---|---|
| Communication | Server ā Client | Server ā Client |
| Connection Model | Repeated Requests | Single Persistent Stream |
| Reconnection Frequency | Frequent | Rare |
| Infrastructure Overhead | Moderate | Lower |
| Browser Support | Excellent | Excellent |
| Automatic Reconnect | Manual Logic | Built-In |
| Streaming Experience | Good | Excellent |
Both approaches solve real problems.
SSE simply removes another layer of overhead.
Where SSE Starts To Break Down
SSE excels at one-way communication.
But some systems require:
Client ā Server
continuous communication.
Examples include:
- Chat applications
- Multiplayer games
- Collaborative editors
- Trading systems
- Video conferencing
These applications need both sides to speak freely.
SSE only provides:
Server ā Client
communication.
At that point, WebSockets usually become the better choice.
The Architect's Lesson
SSE teaches a powerful principle:
Stop asking repeatedly. Start listening continuously.
That small shift helped transform the web from a collection of pages into a platform for real-time experiences.
Stock prices could update instantly.
Dashboards could refresh automatically.
Notifications could arrive immediately.
AI systems could stream responses as they were generated.
The technology itself is relatively simple.
The impact on user experience is enormous.
And that is often the hallmark of great system design:
Small architectural changes can create massive user experience improvements.
TL;DR Quick Recap
- SSE allows browsers to maintain a single HTTP connection.
- The server streams updates whenever events occur.
- Clients listen instead of repeatedly polling.
- SSE is ideal for one-way real-time communication.
- It works well for dashboards, notifications, stock prices, and AI streaming.
- It leverages existing HTTP infrastructure.
- Persistent connections introduce new scaling considerations.
- SSE sits between Long Polling and WebSockets in the evolution of real-time web communication.
Final Thoughts: The Web Learned to Listen š§
Polling taught the web how to ask.
Long Polling taught the web how to wait.
SSE taught the web how to listen.
That change may sound subtle.
But it fundamentally altered how users interact with modern applications.
The web was no longer a collection of pages that occasionally refreshed.
It became a platform capable of delivering information the moment it existed.
For many systems, that was enough.
For others, the journey continued.
Because eventually developers wanted something more than listening.
They wanted a conversation.
And that conversation led to:
WebSockets.
A Little Engineering Joke to End On š
Why did SSE become a great listener?
Because unlike Polling,
it stopped interrupting every few seconds.
Frequently Asked Questions
What is Server-Sent Events (SSE)?
SSE is a browser technology that allows servers to continuously stream updates to clients over a single HTTP connection.
How is SSE different from Polling?
Polling repeatedly asks for updates.
SSE opens one connection and receives updates whenever the server has new information.
How is SSE different from Long Polling?
Long Polling repeatedly creates new waiting requests.
SSE maintains one persistent stream for continuous event delivery.
Is SSE real-time?
For many applications, yes.
Updates are typically delivered immediately after events occur.
Why is SSE commonly used for AI applications?
Because AI responses are generated incrementally and can be streamed token-by-token, creating a more responsive user experience.
When should I use SSE?
SSE is ideal when:
- Data primarily flows from server to client
- Real-time updates are important
- HTTP compatibility matters
- Simplicity is preferred over bidirectional communication
Key Takeaways
- SSE enables server-to-client streaming over HTTP.
- Clients listen instead of repeatedly polling.
- It reduces unnecessary requests.
- It improves perceived responsiveness.
- It works exceptionally well for dashboards, notifications, monitoring, and AI streaming.
- Persistent connections introduce new operational challenges.
- SSE is often the simplest solution for one-way real-time communication.
- Understanding SSE helps explain the evolution toward modern web communication patterns.
If you found this article useful, share it with fellow backend engineers, system architects, platform engineers, and distributed systems enthusiasts exploring communication patterns at scale.
About the Author
Anik Sikder is a Software Engineer specializing in Backend Systems, SaaS Architecture, Cloud Infrastructure, Python, Django, FastAPI, distributed systems, and scalable software engineering.
He writes about system design, networking, distributed systems, cloud computing, software architecture, and modern engineering practices.
