--- type: Leaf title: Server-sent events for live updates description: Server-sent events stream live updates over HTTP without websocket complexity. See when SSE fits and where it breaks in production. resource: https://nationaldigital.com.au/platform-engineering/real-time-systems/server-sent-events/ tags: - platform-engineering - Real-time systems - Platform engineering - API development - System integration - server-sent events - SSE vs websockets - real-time dashboard updates - legacy system modernisation - event-driven architecture - live data streaming timestamp: '2026-10-20T10:02:14.891Z' language: en-AU publisher: National Digital author: Cameron Young authorRole: CEO readingTimeMinutes: 8 wordCount: 1517 datePublished: '2025-10-01' dateModified: '2026-10-20' pillar: platform_engineering canonical: https://nationaldigital.com.au/platform-engineering/real-time-systems/server-sent-events/ --- _Home — Platform Engineering — Real-time systems — Server-sent events for live updates_ # Server-sent events for live updates Server-sent events stream live updates over HTTP without websocket complexity. See when SSE fits and where it breaks in production. **Quick answer:** Server-sent events push live updates to browsers over a single HTTP connection, suiting dashboards and notifications better than polling or full WebSocket infrastructure. ## About this page - Written by Cameron Young, CEO - 8 min read - Updated 20 October 2026 _Real-time systems — Platform engineering — API development — System integration_ ## What are server-sent events and when should they replace polling or WebSockets? Server-sent events push live updates from server to browser over one persistent HTTP connection, suited to dashboards and notification feeds where data flows mainly one way, not two-way chat or input-heavy interactions. **Additional Context** SSE suits one-way feeds such as order status, inventory counts and notification panels; two-way interactions like chat still need a separate request channel alongside the stream. _High confidence · Verified 20 Oct 2026_ *Real-time integration patterns* ## 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](/platform-engineering/real-time-systems/message-queuing), 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](/platform-engineering/real-time-systems/real-time-dashboards) where staff watch numbers change but don't need to send data back down the same channel. *Real-time integration* ## Live Data Without the Websocket Build **Problem:** Operations teams want dashboards, order queues and support tickets to update the moment something changes, but refreshing pages or polling an API every few seconds wastes server capacity and still leaves a lag between the change and what staff see on screen. **Common Pain Points** - **Dashboards lag behind reality** — Staff make decisions on data that's minutes old because the screen only refreshes on a timer. - **Polling load grows with every new screen** — Each additional dashboard or integration adds another scheduled API call, even when nothing has changed. - **WebSocket infrastructure feels like overkill** — Full duplex messaging brings connection pooling and scaling complexity a one-way feed doesn't actually need. **Business Impact** - Time Wasted: Engineering time spent tuning polling intervals and chasing stale-data bugs - Cost Implication: Repeated API calls firing on a schedule whether or not the underlying data changed - Opportunity Cost: Staff acting on information that's minutes out of date during the busiest periods **Solution:** Replace scheduled polling with a persistent server-sent events stream that pushes each change to connected dashboards the moment it happens, using standard HTTP that existing infrastructure already supports. **Our Approach** 1. **Map the data that actually needs to be live** _(Typically 1-2 weeks)_: Identify which screens need second-by-second updates, such as order status or queue counts, versus which can tolerate a slower refresh, since not every field justifies a persistent connection. 2. **Build the stream endpoint and test the path it travels** _(Typically 2-4 weeks depending on existing infrastructure)_: Implement the SSE endpoint, then check every proxy, load balancer and CDN in front of it for response buffering or idle timeouts that would silently break the stream in production. **Expected Outcome:** Dashboards and queue views that reflect a change within moments of it happening, running on infrastructure the business already operates. *Key Takeaways* ## SSE delivers live updates with far less infrastructure than WebSockets Server-sent events suit one-way live data such as dashboards, order status and notifications, and cost less to operate than WebSockets, provided the infrastructure around them is configured correctly. - **SSE needs only standard HTTP, not a new protocol stack** Because SSE rides over plain HTTP, existing load balancers, firewalls and API gateways mostly handle it without new infrastructure, unlike WebSockets which often need dedicated connection handling. _Important_ - **Reconnection and event ordering are handled automatically** The browser's EventSource API reconnects after a dropped connection and resumes using the Last-Event-ID header, removing a class of bugs teams otherwise have to build and test themselves. _Important_ - **SSE only pushes data one way, from server to client** Any client input such as form submissions or chat messages still needs a normal API call alongside the stream, which matters when scoping dashboards versus collaborative tools. _Critical_ - **Proxies and load balancers often buffer or time out long connections** Nginx, CloudFront and some corporate proxies buffer responses by default, which silently breaks SSE in production even when it works perfectly in local development. _Critical_ ## SSE Protocol Behaviour and Browser Limits Server-sent events rely on browser and HTTP behaviour that is standardised but easy to miss when teams estimate infrastructure needs for live dashboards. - **Reconnection method: Automatic via Last-Event-ID** _Significance: high_ — The EventSource interface automatically reconnects after a dropped connection and resumes the stream from the last event ID without custom client code. _(Source: WHATWG HTML Living Standard)_ - **Browser connection cap: 6 per domain (HTTP/1.1)** _Significance: medium_ — Most browsers limit concurrent connections to a single domain under HTTP/1.1, which matters when a page opens several SSE streams alongside normal API calls. _(Source: Browser HTTP/1.1 connection pooling behaviour)_ - **Data direction: Server to client only** _Significance: high_ — SSE carries no channel for client-to-server messages, so any user input on a live dashboard still travels over a separate standard API request. _(Source: HTML living standard, EventSource section)_ **Methodology:** Figures below reflect published web standards and documented browser connection handling rather than a market survey, and apply to HTTP/1.1 unless otherwise noted. *Production considerations* ## 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](/platform-engineering/real-time-systems/legacy-application-modernisation) 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](/platform-engineering/real-time-systems/api-development-best-practices) 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. ## Thinking Through a Live Data Project? National Digital helps operations and IT teams work out whether server-sent events, WebSockets or a queue-based approach fits their existing systems, then builds and integrates it without disrupting what's already running. - [Book a Platform Review](https://calendly.com/cameron-at-national-digital/discovery) - [Email Our Team](mailto:enquiries@nationaldigital.com.au) - Email: enquiries@nationaldigital.com.au - Phone: 1300 800 855 ## Server-Sent Events: Common Questions ### How is SSE different from WebSockets for live data feeds? SSE sends data in one direction only, from server to browser, over a standard HTTP connection that most infrastructure already handles. WebSockets open a full duplex channel for two-way messaging, which suits chat or collaborative editing but adds connection pooling and scaling work that a one-way dashboard or notification feed doesn't need. ### Does SSE work through corporate proxies and load balancers? Mostly, but not automatically. SSE rides over plain HTTP, so most firewalls and gateways pass it through without special configuration. The common failure is response buffering: some proxies, CDNs and load balancers hold the stream open but buffer the data before forwarding it, which delays or silently drops updates until buffering is disabled for that endpoint. ### Can SSE streams safely carry personal information? Yes, with the same safeguards any API carrying personal information needs: authentication on the connection, encryption in transit, and access scoped to what each user should see. Under the Australian Privacy Principles, APP 11 requires reasonable steps to secure personal information, which applies to a live stream exactly as it applies to any other data channel. ### When does polling beat SSE for keeping data current? Polling still makes sense when updates are infrequent, say once an hour, or when the client needs to control exactly when it checks rather than reacting to server-pushed events. For data that changes every few seconds and is viewed continuously, such as a live order queue, a persistent SSE stream avoids the repeated connection overhead frequent polling creates. ### How many concurrent SSE connections can one server handle? It depends on the runtime and how connections are held open. A single Node.js process can typically sustain several thousand idle SSE connections before memory becomes the limiting factor, since each one only needs a lightweight open socket rather than ongoing processing. Horizontal scaling behind a load balancer becomes standard practice as production traffic grows beyond a single server's capacity. ### Does adding SSE mean rebuilding a legacy system first? Not necessarily. SSE can often sit in front of an existing legacy system as a thin streaming layer, polling the legacy database internally and pushing changes out to browsers, which avoids touching the legacy code itself. That staged approach is usually lower risk than rewriting the underlying system purely to add live updates. ## Related reading - [Message queuing across Australian time zones](/platform-engineering/real-time-systems/message-queuing/) - [Real-time dashboards and timezone sync](/platform-engineering/real-time-systems/real-time-dashboards/) - [Legacy Application Modernisation](/platform-engineering/real-time-systems/legacy-application-modernisation/) - [Platform Engineering Anti Patterns](/platform-engineering/real-time-systems/platform-engineering-anti-patterns/) - [Golden Path Platform Engineering](/platform-engineering/real-time-systems/golden-path-platform-engineering/) - [Pos System Integration](/platform-engineering/real-time-systems/pos-system-integration/) ## Related **Parent:** - [Real-time systems](/okf/platform-engineering/real-time-systems.md) **Related:** - [Legacy Application Modernisation](/okf/platform-engineering/real-time-systems/legacy-application-modernisation.md) - [Platform Engineering Anti Patterns](/okf/platform-engineering/real-time-systems/platform-engineering-anti-patterns.md) - [Golden Path Platform Engineering](/okf/platform-engineering/real-time-systems/golden-path-platform-engineering.md) - [Pos System Integration](/okf/platform-engineering/real-time-systems/pos-system-integration.md) - [Api Development Best Practices](/okf/platform-engineering/real-time-systems/api-development-best-practices.md) # Citations - [OAIC — APP 11: Security of Personal Information](https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-11-app-11-security-of-personal-information) — APP 11 requires reasonable steps to protect personal information from misuse, loss and unauthorised access, a requirement that extends to persistent data streams carrying customer or operational data.