Server-Sent Events (SSE) Implementation Template

Use SSE when the communication is primarily server-to-client (dashboards, notifications, status updates, live feeds). SSE is simpler to implement, works through HTTP proxies, has built-in reconnection, and uses standard HTTP. Use WebSockets when you need bidirectional communication (chat, collaborative editing, gaming). For a deeper comparison of real-time technologies, the [Technical PM Handbook](/technical-pm-guide) covers architecture trade-offs for real-time features.

Yes. A single Node.js process can handle 10,000+ concurrent SSE connections because each connection is a lightweight long-lived HTTP response, not a CPU-intensive operation. The bottleneck is usually the event fan-out: pushing events to thousands of connections. Use a pub/sub system (Redis Pub/Sub, Kafka) to fan out events to server instances, then each instance pushes to its local connections.

The `EventSource` API does not support custom headers. The three options are: (1) pass a JWT as a query parameter, (2) use an HttpOnly cookie set during login, or (3) POST to an auth endpoint first to get a short-lived session ID, then pass that to the SSE endpoint. Option 2 (cookies) is the most secure for same-origin requests. Option 1 (query param) is simplest but exposes the token in server logs and browser history.

All SSE connections drop. Each client's `EventSource` automatically reconnects after the `retry` interval. The server must handle the `Last-Event-ID` header to replay missed events. Store events in a durable buffer (Redis, database) so they survive server restarts. Without a durable buffer, clients miss events during the restart window. For short-lived events (metrics that update every 5 seconds), sending a full state snapshot on reconnect is simpler than event replay. ---