Server-Sent Events (SSE)
A one-way HTTP stream where the server pushes events to the browser over a long-lived connection. Simpler than WebSockets for server→client updates, with automatic reconnection and built on HTTP. No client→server channel.
- Server→client notifications, live updates, AI token streaming.
- When you want HTTP semantics and auto-reconnect.
- Bidirectional chat (use WebSockets).
- Very high-frequency binary streams.
Definition
SSE uses a standard HTTP response with text/event-stream content type; the server writes events (id, event type, data) and keeps the connection open. The browser EventSource API auto-reconnects and resumes via Last-Event-ID.
Why it exists
Many realtime needs are one-way (notifications, live scores). SSE reuses HTTP infra (proxies, caching, auth headers) and gives free reconnection, far simpler than WebSockets for that case.
How it works
Client opens EventSource to an endpoint. Server sets Content-Type: text/event-stream and writes `data: ...\n\n` frames. On disconnect, the browser reconnects with Last-Event-ID so the server can resume. Works through normal HTTP/2.
Scaling limits
One connection per client is stateful like WebSockets; same scaling concerns (memory, fan-out broker). Browser limits concurrent SSE connections per origin (HTTP/1.1); HTTP/2 lifts this.
Cost shape
Memory per open connection. Cheaper/simpler than WebSockets for one-way push since it's plain HTTP.
Alternatives
- WebSockets — Bidirectional, but more complex and no auto-reconnect built in.
- Long polling — No special server support, but higher overhead.
Failure modes
- HTTP/1.1 connection-per-origin limits blocking other requests.
- Proxies buffering events (must disable buffering).