When should I use SSE instead of WebSocket?

Use SSE when data flows only from server to client (notifications, live feeds, progress updates). Use WebSocket when you need bidirectional communication (chat, collaborative editing, multiplayer games).

Does SSE work through load balancers?

Yes. SSE uses standard HTTP, so it works through load balancers, proxies, and CDNs without special configuration. WebSocket requires protocol upgrade support, which some proxies do not handle correctly.

How many SSE connections can a server handle?

Each SSE connection is a long-lived HTTP connection, consuming a file descriptor on the server. Modern servers can handle tens of thousands of concurrent connections. For higher scale, use a dedicated event streaming service.

Server-Sent Events Explained

Real-time server-to-client streaming over standard HTTP — simple, automatic reconnection, and no special infrastructure.

Server-Sent Events

Server-Sent Events (SSE) is a standard for pushing real-time updates from a server to a client over a single, long-lived HTTP connection, using a simple text-based protocol built on top of standard HTTP.

Explanation

Traditional HTTP is request-response: the client asks, the server answers, and the connection closes. For real-time updates (live scores, notifications, stock tickers), the client would need to poll — repeatedly asking "any updates?" — which wastes bandwidth and adds latency. SSE solves this with a persistent, one-directional stream. The client opens an SSE connection using the EventSource API (built into all browsers). The server holds the connection open and sends events as they occur, formatted as simple text lines: event type, data payload, and optional ID for resume tracking. If the connection drops, the browser automatically reconnects and uses the last event ID to request missed events. SSE is simpler than WebSocket for server-to-client streaming because it uses standard HTTP (works through proxies, load balancers, and firewalls without special configuration), supports automatic reconnection, and requires no special server infrastructure. The trade-off: SSE is unidirectional (server to client only). If you need bidirectional communication, use WebSocket instead.

Bookuvai Implementation

Bookuvai uses Server-Sent Events for features like live progress updates, notification feeds, and real-time dashboard data. Our SSE implementation includes event ID tracking for reconnection resilience, heartbeat messages to keep connections alive through proxies, and graceful degradation to polling for clients that do not support SSE.

Key Facts

SSE uses standard HTTP — no special server infrastructure needed
Built-in browser reconnection with last-event-ID resume
Unidirectional: server to client only (use WebSocket for bidirectional)
EventSource API is supported in all modern browsers
Text-based protocol — simpler than WebSocket binary frames

Related Terms

Frequently Asked Questions

When should I use SSE instead of WebSocket?: Use SSE when data flows only from server to client (notifications, live feeds, progress updates). Use WebSocket when you need bidirectional communication (chat, collaborative editing, multiplayer games).
Does SSE work through load balancers?: Yes. SSE uses standard HTTP, so it works through load balancers, proxies, and CDNs without special configuration. WebSocket requires protocol upgrade support, which some proxies do not handle correctly.
How many SSE connections can a server handle?: Each SSE connection is a long-lived HTTP connection, consuming a file descriptor on the server. Modern servers can handle tens of thousands of concurrent connections. For higher scale, use a dedicated event streaming service.