Server-Sent Events

Server-Sent Events (SSE) is a standard for pushing real-time updates from server to client over a single HTTP connection, with built-in reconnection, event IDs, and a simple text-based protocol.

What It Really Means

SSE is the simplest way to stream data from a server to a browser. Unlike WebSockets, which provide bidirectional communication, SSE is one-way: the server sends events to the client. The client uses the standard EventSource API to receive them.

What makes SSE compelling is what you get for free: automatic reconnection (the browser reconnects if the connection drops), event IDs (the server can resume from where the client left off), and standard HTTP infrastructure (works with proxies, load balancers, CDNs, and HTTP/2 without special configuration).

For many real-time use cases — live dashboards, notification feeds, stock tickers, build logs, AI chat responses — the data flows in one direction: server to client. SSE is the right tool for these. WebSockets are only necessary when the client needs to send frequent messages back to the server (chat, gaming, collaborative editing).

How It Works in Practice

SSE Protocol

SSE uses a simple text-based format over HTTP:

Fields:

• data: — the event payload (can span multiple lines)
• event: — custom event type (defaults to "message")
• id: — event ID for resumption after reconnection
• retry: — reconnection delay in milliseconds
• Lines starting with : — comments (used as keep-alive pings)
• Blank line — separates events

Automatic Reconnection

Implementation

Server (Python with Flask):

Client (JavaScript):

Trade-offs

SSE vs WebSocket:

Choose SSE when:

• Updates flow from server to client only
• You want automatic reconnection and event replay
• You need compatibility with HTTP infrastructure
• The data is text-based (JSON, text)

Choose WebSocket when:

• You need bidirectional communication
• You need to send binary data
• You need very low latency (< 50ms)
• HTTP/1.1 connection limits are a concern

Common Misconceptions

• "SSE is inferior to WebSockets" — SSE is simpler, more reliable (auto-reconnect), and works better with HTTP infrastructure. For server-to-client streaming, SSE is usually the better choice.
• "SSE is limited to 6 connections" — This limit applies to HTTP/1.1. With HTTP/2, all SSE streams are multiplexed on a single connection. There is no practical limit.
• "SSE cannot send different event types" — SSE supports named events with the event: field. Clients can listen for specific event types.
• "SSE does not work with authentication" — EventSource does not support custom headers, but you can pass tokens via URL query parameters or cookies.

How This Appears in Interviews

1. "Design a live dashboard for monitoring" — SSE for streaming metrics to the browser. Discuss reconnection, event IDs for resumption, and scaling.
2. "How do AI chatbots stream responses?" — SSE is the standard approach (used by ChatGPT, Claude). Token-by-token streaming over a single HTTP connection.
3. "Compare real-time communication options" — SSE for server-to-client, WebSocket for bidirectional, long polling as a fallback.
4. "Design a notification system" — SSE for real-time delivery. Discuss how to handle offline users (persist notifications, deliver on reconnect using event IDs).

Related Concepts

• WebSocket Protocol — bidirectional alternative for two-way communication
• Long Polling — predecessor to SSE for server-push patterns
• HTTP/2 Multiplexing — SSE works best over HTTP/2 connections
• Change Data Capture — source of real-time events to stream via SSE
• System Design Interview Guide
• Algoroq Pricing — access all concept deep-dives