Server-sent events for live updates

What server-sent events solve

A server-sent event (SSE) is a single, long-lived HTTP connection that a server keeps open to push text updates to a browser as they happen, rather than the browser asking for them on a schedule. The browser's built-in EventSource API handles the connection, reconnects automatically if it drops, and resumes from the last event it received using a Last-Event-ID header. For a business, that means a stock level panel, a support ticket queue or a job status screen can update the instant the underlying record changes, without a developer writing retry logic or a reconnection timer.

SSE sits inside the broader shift toward event-driven architecture, where a change in one system triggers a message rather than waiting to be discovered on the next poll. The difference with SSE is that the event travels all the way to the browser over plain HTTP, so most of the infrastructure a business already runs, its load balancer, its API gateway, its existing authentication, handles it with little extra configuration.

SSE versus WebSockets and scheduled polling

Polling an API every few seconds is the easiest thing to build and the easiest thing to outgrow: every dashboard, every open tab, every integration adds another scheduled request, whether or not anything changed. WebSockets solve the opposite problem, a full two-way channel for chat or collaborative editing, but bring connection pooling, horizontal scaling and protocol complexity that a one-way status feed doesn't need. SSE occupies the middle ground, a persistent connection built on plain HTTP, which is usually the better fit for real-time dashboard architecture where staff watch numbers change but don't need to send data back down the same channel.

Running SSE in production

The gap between an SSE demo and an SSE system that holds up in production is almost always the network path in between. Nginx, CloudFront, some corporate proxies and a handful of enterprise firewalls buffer HTTP responses by default, holding the stream open but not forwarding bytes until a buffer fills or a timeout fires. A connection that streams instantly on a developer's laptop can sit silent for thirty seconds in front of a production load balancer, and the fix is almost always a configuration change, disabling response buffering and extending the idle timeout for that specific endpoint, not a code change in the application itself. Teams that skip this check in staging usually find it the hard way once a dashboard goes live and staff report updates arriving in bursts instead of continuously.

Where SSE fits in a modernisation plan

SSE rarely requires touching the system of record. A common pattern for staged system migration work is to build a thin streaming layer that polls the legacy database or message queue internally on the server side, then pushes changes out to browsers over SSE, leaving the legacy application untouched. That keeps the live-update project separate from, and much smaller than, any wider application modernisation effort, and it follows the same API-first development discipline that makes the stream easy to extend once the first dashboard proves the approach. Where personal or operational data travels through the stream, the usual API security controls, authentication on connect and encrypted transport, apply exactly as they would to any other endpoint.