Server-Sent Events (SSE) Architecture for Unidirectional Real-Time Streaming
SSE provides a unidirectional HTTP event format and EventSource reconnection; event history, replay, and complete delivery remain application responsibilities.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Protocol structure and EventSource behavior
Server-Sent Events (SSE) is consumed through the browser’s EventSource API, which reads a UTF-8 event stream from an HTTP response. Unlike WebSocket, the browser API is designed for receiving server-to-client events. The standard defines the stream format and client behavior; it does not provide an event database or application-level recovery service.
The response uses the text/event-stream media type. Fields such as data:, event:, id:, and retry: are parsed line by line; a blank line dispatches an event and a line beginning with a colon is a comment. When reconnecting, EventSource can send the last event ID it received in Last-Event-ID, but the application must retain history, interpret the cursor, and replay events if it needs recovery. The standard says the user agent may set Accept: text/event-stream; page code cannot use the EventSource constructor to set arbitrary request headers.
Expert perspective: a reconnect cursor is not event recovery
In an implementation article on LLM streaming, Amber Dawson, Content Lead at Ably, separates the Last-Event-ID reconnect handshake from the work required to resume a stream. The browser can report the last event ID it processed; the application still needs retained history, a lookup by cursor, ordered replay, and policies for duplicates and expired history. Dawson’s discussion reflects an Ably implementation perspective, not a guarantee made by the SSE protocol. The WHATWG standard defines client reconnection behavior, not a server-side event log or replay service.
Operational design: protocol rules versus deployment behavior
EventSource consumes UTF-8 text events from a server. After a recoverable disconnect it retries, and when an event has an id: field the reconnect request can carry Last-Event-ID. The API does not expose arbitrary request-header configuration; the standard says a user agent may set Accept: text/event-stream. A successful response must use text/event-stream. Buffering, idle timeouts, connection limits, and proxy behavior depend on the server, intermediaries, browser, and negotiated HTTP version. HTTP/2 can multiplex streams on a connection, but does not guarantee that an SSE stream will remain open, arrive without delay, or recover every event. Test the complete route, including load balancers and proxies.