Premium Video

This video is available to premium subscribers only

Unlock Full Access

Suppose you are building a metrics dashboard. The server receives new data continuously, and the dashboard should update whenever something changes.

What you really want is for the browser to connect once and let the server send new data whenever it becomes available. That is exactly what Server-Sent Events (SSE) provide.

This chapter covers how SSE works, what its events look like, how reconnection and replay work, how to scale it, the operational challenges of long-lived connections, and when to use it.

One option for the dashboard is polling. The browser sends a request every few seconds asking whether there is anything new.

This works, but it creates a trade-off:

Long polling improves this, but every response still closes the request and forces the browser to ask again.

SSE removes the trade-off. The browser connects once, and the server pushes each update the moment it exists.

Server-Sent Events let a server continuously push updates to a client over HTTP.

The client sends a normal HTTP request. Instead of returning a response and closing the connection, the server keeps the response open. Whenever new data becomes available, the server sends another event over that same connection, and the client receives it immediately.

The key limitation is that SSE is one-way. The server can continuously send data to the client, but the client cannot send messages back over the same connection. If the client needs to send data to the server, it uses a separate HTTP request, such as a normal POST.

For a dashboard, a feed, or a progress bar, that is fine: the server talks and the browser listens.

In a browser, SSE is used through the EventSource API. The client connects to an endpoint exposed by the server:

The server responds with a special content type, text/event-stream. Instead of closing the response, it keeps the connection open and continues sending events over it.

Here is a small Node.js endpoint that does this:

EventSource moves through three states:

The SSE event format is intentionally simple. Each event is a few lines of text followed by a blank line:

Each event usually contains some data. That data might be plain text or JSON.

Events can also have a type, which lets the client tell different kinds of updates apart. The same stream could carry notification events, order status events, and progress events, and the client registers a separate listener for each.

Events can also have an ID. That becomes useful if the connection breaks and the client needs to continue from where it left off.

For multi-line data, repeat the data field:

So although the protocol is simple, it already includes the features a long-lived streaming connection needs.

One useful feature of SSE is automatic reconnection. If the connection drops, the browser automatically tries to reconnect, so you do not need to write basic retry logic yourself.

By default, browsers wait about 3 seconds before reconnecting. The server can suggest a different delay with the retry field:

But this raises another question: what happens to events sent while the client was disconnected?

SSE handles this with a mechanism called Last-Event-ID.

The server assigns an ID to each event, and the browser keeps track of the most recent one it received. If the connection drops, the browser reconnects and sends that ID in the Last-Event-ID header. The server uses it to work out where the stream left off.

For example, if the client last received event 100, the server can replay events 101 onward.

But SSE does not store those events for you. The browser remembers the last ID, and the server has to be able to look up what came after it. Reliable replay requires durable storage such as a database, cache, event log, or message broker.

So Last-Event-ID helps resume the stream, but durability is still the application's responsibility.

Now suppose there are multiple SSE servers behind a load balancer.

When a client opens an SSE connection, the load balancer routes it to one server, and the connection stays there until it closes. So different users end up connected to different SSE servers.

If a backend service generates an event for Bob, the system has to route that event to the server currently holding Bob's connection. The service that produced the event has no idea which server that is.

A common solution is a shared messaging layer:

This keeps business services separate from the servers that manage long-lived connections.

The messaging layer could be Redis Pub/Sub, Kafka, or another event system, depending on your requirements.

Either way, the roles stay the same. Backend services produce events, the messaging layer distributes them, and SSE servers manage client connections and deliver updates. This separation makes the system easier to scale horizontally: add SSE servers for more connections without touching the producers.

Another challenge is slow clients. If the server produces events faster than a client can consume them, buffered data for that client keeps growing and can eventually consume significant memory.

So SSE servers need a backpressure strategy: a rule for what to do when a client cannot keep up. Common options:

SSE connections may stay quiet for long periods. Proxies, load balancers, and other infrastructure can close them as idle.

A common solution is to send periodic heartbeats. Lines that start with : are comments, which the browser ignores, so they make good heartbeats:

Heartbeats carry no meaningful data. They keep the connection alive and help detect failures. Send them more often than the shortest idle timeout along the request path.

The other concern is response buffering. SSE relies on streaming data through a long-lived HTTP response, but some proxies, CDNs, and middleware buffer response data before forwarding it. If that happens, an event the server sent immediately may reach the client several seconds later.

So the entire HTTP path must support streaming correctly, with compatible idle timeouts and buffering disabled where needed. In Nginx, for example, teams commonly send the X-Accel-Buffering: no header, as the server example above does.

Long-lived connections also affect deployments.

If an SSE server with thousands of active clients shuts down immediately, all those clients disconnect and may reconnect at once. That creates a sudden traffic spike on the remaining servers.

A better approach is connection draining:

Because clients resume with Last-Event-ID, moving to another server does not lose events.

SSE is a strong choice when you need frequent server-to-client updates without a fully bidirectional connection. Common use cases:

If both the browser and the server need to send frequent messages on the same connection, WebSockets are a better fit.

A popular modern use case for SSE is streaming in LLM applications.

When a user sends a prompt, generating the full response may take several seconds. Instead of waiting for the entire answer, the server streams it as it is generated:

This makes the application feel much more responsive, because the user starts seeing results almost immediately.

It is a natural server-to-client streaming pattern: the client sends one request, and the server progressively sends the response back.

Polling forces a choice between wasted requests and delayed updates. SSE lets the browser connect once while the server pushes events over a long-lived HTTP response with the text/event-stream content type. It is one-way: anything the browser sends goes through separate requests.

Events are simple text with data, an optional type, and an optional ID. Browsers reconnect automatically and send Last-Event-ID, but replaying missed events needs durable storage on the server side.

To scale, a messaging layer such as Redis Pub/Sub or Kafka routes each event to the server holding the client's connection. In production, plan for slow clients with a backpressure strategy, keep quiet connections alive with heartbeats, disable buffering along the path, and drain connections during deployments.

SSE fits notifications, dashboards, job progress, feeds, and streaming AI responses: anywhere the server talks and the browser listens.