Stackbook Logo
distribution-communicationestablished · low operational burden

Server-Sent Events

Also known as: sse, eventsource

Intent

Stream one-way server-to-client updates over a long-lived HTTP response.

Problem

Clients need live updates such as notifications or progress, but polling wastes requests and adds delay. Full duplex channels are heavier than needed when the client never sends data on the stream.

Forces

  • •Updates are server-initiated and one-directional
  • •Must work through ordinary HTTP infrastructure
  • •Clients reconnect and must not lose events
  • •Many open connections consume server resources

Solution

Overview

Server-Sent Events (SSE) is a standard way for a server to push a stream of text events to a browser over a single HTTP connection. It is simpler than WebSockets and fits any feed where data flows only from server to client.

How it works

The server responds with content type text/event-stream and never completes the response. Events are separated by blank lines.

GET /stream HTTP/1.1
Accept: text/event-stream

id: 105
event: price
data: {"sym":"ACME","px":41.2}

: heartbeat

In the browser, new EventSource("/stream") opens the connection and fires handlers per event name. If the connection drops, EventSource reconnects after a delay and sends the Last-Event-ID header. The server uses that id to replay events from a short buffer or log. Heartbeat comments every 15 to 30 seconds prevent idle timeouts at load balancers.

Pitfalls

  • Proxy or gateway buffering. Disable response buffering and compression for the stream path.
  • No replay. Without ids and a retained buffer, reconnects silently lose events.
  • Reconnect storms. Add jitter via the retry field and cap connections per user.
  • Using SSE where the client must also stream upward; use WebSockets instead.
  • Authentication tokens in URLs, since EventSource cannot set custom headers. Prefer cookies or a short-lived ticket.

Key takeaways

  • One-way push over plain HTTP with automatic reconnect.
  • Use event ids and a replay buffer for reliable delivery.
  • Send heartbeats and disable proxy buffering.
  • Choose WebSockets only when you need client-to-server streaming.

✓ When to Use

  • •Live feeds, notifications, progress bars, dashboards
  • •Server pushes only; client uses normal requests to send data
  • •Environments where WebSockets are blocked or unneeded

✗ When Not to Use

  • •Bidirectional low-latency messaging such as games or chat typing
  • •Binary payloads
  • •Very large numbers of connections without a suitable async server

Pros

  • +Simple protocol over plain HTTP
  • +Built-in reconnection and resume
  • +Works with standard auth and HTTP semantics

Cons

  • −One-way only
  • −Text only, with per-domain connection limits on HTTP/1.1
  • −Long-lived connections strain servers and proxies

Cost Profile

Infrastructure

Low - no special infrastructure

Operational

Medium - connection capacity and buffering proxies

Cognitive

Low - small protocol

Failure Modes

  • Proxy buffering delays or swallows events

  • Lost events on reconnect without id-based replay

  • Connection storms after a server restart

Real-World Examples

Alternatives

    Related Patterns

      Competency Domains

      distribution communicationreliability ops