Server-Sent Events (SSE): When the Web Learned to Listen

Mon, 27 Jul 2026 18:26:08 +0000

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 that servers couldn't produce updates quickly.

The challenge was getting those updates to users immediately.

And that led engineers down a fascinating path:

Request-Response
        ↓
Polling
        ↓
Long Polling
        ↓
Server-Sent Events (SSE)

SSE wasn't just another protocol.

It was the web's attempt to become truly real-time while still staying within the familiar world of HTTP.

The Business Problem Nobody Could Ignore

Imagine you're running a stock trading platform.

At market open, prices can change thousands of times every second.

Your users expect something like this:

AAPL  $202.15
MSFT  $541.22
NVDA  $193.47

And when prices change:

AAPL  $202.31
MSFT  $541.40
NVDA  $193.61

The update should appear instantly.

Not five seconds later.

Not after a page refresh.

Not after clicking a button.

Immediately.

From a business perspective, this sounds simple:

"Show customers the latest information as soon as it changes."

From a system design perspective, it's much harder.

How does the browser know when something changes?

The First Attempt: Polling

The most obvious solution was polling.

The browser repeatedly asked:

Any updates?

Every few seconds.

Browser
    │
    ├── Request
    ├── Request
    ├── Request
    ├── Request
    └── Request

Most of the time the server replied:

Nothing changed.

Imagine 100,000 users checking every second.

Even when no new information existed:

100,000 Requests
          ↓
100,000 Responses
          ↓
No Useful Data

The system was working hard to accomplish almost nothing.

The architecture scaled poorly.

Infrastructure costs increased.

Servers processed millions of unnecessary requests.

Engineers needed something better.

The Second Attempt: Long Polling

Long Polling improved efficiency.

Instead of responding immediately, the server waited.

Browser Request
       ↓
Server Waits
       ↓
Event Happens
       ↓
Server Responds

If a stock price changed, the server responded instantly.

If nothing happened, the connection stayed open.

This dramatically reduced useless requests.

But Long Polling still had a problem.

After every response:

Response Received
        ↓
Create New Request
        ↓
Wait Again

The cycle never truly disappeared.

The browser was still repeatedly initiating communication.

Just less frequently.

The Simple Question That Changed Everything

Eventually engineers asked:

Why is the browser constantly asking for updates?

If the server already knows when something changes, why not let the server send the update directly?

That question led to Server-Sent Events.

What Is Server-Sent Events (SSE)?

Server-Sent Events allow a browser to open a single HTTP connection and keep it alive.

Instead of repeatedly asking for information, the browser simply listens.

Browser
     │
     │ Open Connection
     ▼
Server
     │
     ├── Event
     ├── Event
     ├── Event
     └── Event

The server pushes updates whenever something happens.

No polling loop.

No repeated requests.

No constant reconnecting.

The browser becomes a subscriber.

The server becomes a publisher.

A Different Way of Thinking

Polling asks:

Did anything happen?
Did anything happen?
Did anything happen?
Did anything happen?

SSE says:

Tell me when something happens.

That sounds like a small difference.

Architecturally, it's huge.

Inside a Real SSE Connection

From the browser's perspective, creating 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

But unlike a normal HTTP response, the server doesn't close the connection.

Instead, it keeps streaming data.

data: New Order Created

data: Payment Received

data: Shipment Dispatched

The browser receives each event immediately.

The connection remains open.

The stream continues.

Real System Example: E-Commerce Operations Dashboard

Consider a large e-commerce company.

The operations team monitors incoming orders in real time.

Without SSE:

Dashboard
    ↓
Poll Every 5 Seconds
    ↓
Check For New Orders

A customer places an order.

The operations team might not see it for several seconds.

With SSE:

Customer Places Order
          ↓
Order Service
          ↓
Event Bus
          ↓
Notification Service
          ↓
SSE Gateway
          ↓
Dashboard

The moment the order is created:

New Order Received

appears on the dashboard.

No refresh required.

No polling required.

To the user, the system feels alive.

Real System Example: Monitoring Platforms

Modern monitoring tools often display:

CPU utilization
Memory usage
Error rates
Request latency
Active users

Imagine a platform monitoring thousands of servers.

Every metric changes continuously.

Polling every few seconds creates unnecessary traffic.

Instead:

Monitoring Agent
  ↓
Metrics Service
  ↓
Event Stream
  ↓
SSE
  ↓
Dashboard

As metrics change, updates appear instantly.

Operations teams gain near real-time visibility into system health.

Real System Example: AI Response Streaming

Today, one of the most recognizable uses of SSE is AI.

When you ask ChatGPT a question, the model doesn't generate an entire response instantly.

It generates tokens one at a time.

Without streaming:

User Question
       ↓
Wait 10 Seconds
       ↓
Entire Answer Appears

From the user's perspective:

System feels slow.

With SSE:

User Question
       ↓
Wait 1 Second
       ↓
Words Begin Appearing
       ↓
Response Continues Streaming

The total generation time may still be ten seconds.

But the experience feels dramatically faster.

This reveals an important system design principle:

Users experience latency differently than systems measure latency.

A ten-second wait feels frustrating.

A ten-second stream feels interactive.

SSE helps bridge that gap.

This is one reason AI products feel conversational rather than delayed.

Why Product Teams Love SSE

From a product perspective, SSE improves perceived responsiveness.

Users don't care how elegant your architecture is.

They care about what they see.

Compare:

Click
     ↓
Wait
     ↓
Wait
     ↓
Wait
     ↓
Response

Versus:

Click
     ↓
Response Starts
     ↓
More Content
     ↓
More Content

The second experience feels dramatically faster even if total processing time is identical.

That translates directly into:

Better engagement
Better user satisfaction
Higher retention
More trust in the product

Why Developers Love SSE

One reason SSE became popular is that it works with existing HTTP infrastructure.

There is no entirely new protocol to learn.

Browser
   ↓
HTTP
   ↓
Load Balancer
   ↓
Reverse Proxy
   ↓
Application Server

Everything already understands HTTP.

This makes adoption much easier.

Developers also benefit from automatic reconnection.

If a connection drops:

Connection Lost
        ↓
Browser Detects Failure
        ↓
Automatic Reconnect

The browser handles much of the recovery logic automatically.

Less code.

Less complexity.

Fewer edge cases.

Why Architects Choose SSE

A common question is:

Why not just use WebSockets?

The answer depends on communication patterns.

Consider stock prices:

Market
   ↓
User

Or monitoring dashboards:

Server
   ↓
Dashboard

Or AI response streaming:

Model
   ↓
Browser

In all of these systems:

Server talks constantly.
Client rarely talks.

SSE fits naturally.

WebSockets support two-way communication:

Client ↔ Server

But many systems don't need that capability.

Using WebSockets in these situations can introduce complexity without delivering meaningful benefits.

One of the most important lessons in architecture is:

The best solution is not the most powerful one. It's the simplest one that satisfies the requirements.

For many one-way streaming workloads, SSE is exactly that solution.

The Hidden Challenge

Every architectural improvement introduces a new bottleneck.

Polling creates too many requests.

SSE solves 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.

The connection management problem appears.

Infrastructure teams now worry about:

Memory consumption
File descriptor limits
Load balancer behavior
Proxy timeouts
Reconnection storms
Horizontal scaling

From an operations perspective:

Fewer Requests
≠
Less Work

The workload simply shifts.

Where SSE Starts To Break Down

SSE is excellent for one-way communication.

But some systems require continuous communication in both directions.

Examples include:

Chat applications
Multiplayer games
Collaborative editors
Trading platforms
Video conferencing systems

These applications need:

Client ↔ Server

communication.

SSE only provides:

Server → Client

At that point, WebSockets usually become the better architectural choice.

What SSE Really Changed

Server-Sent Events didn't introduce a revolutionary new protocol.

Its impact came from a much simpler idea:

Stop asking repeatedly.

Start listening continuously.

That shift helped transform the web from a collection of documents into a platform for real-time experiences.

Stock prices could update instantly.

Dashboards could refresh automatically.

Notifications could arrive the moment events occurred.

AI systems could stream responses as they were generated.

The technology itself is relatively simple.

The effect on user experience is enormous.

And that is often the hallmark of great system design:

A small architectural change that fundamentally improves how users experience a system.

The Evolution Continues

The web's journey toward real-time communication didn't stop with SSE.

Request-Response
   ↓
Polling
   ↓
Long Polling
   ↓
Server-Sent Events (SSE)
   ↓
WebSockets

SSE taught the web how to stream information.

WebSockets would teach the web how to have a conversation.

And that's where the next chapter begins.

Coder Legion - Recent posts tagged server-sentevents