Server-Sent Events Event Stream

Server-Sent Events (SSE) delivers a persistent HTTP response containing a sequence of server-to-client events in a defined text-based format. It is useful when a Java backend needs to push updates to a browser or other HTTP client without requiring bidirectional messaging.

An SSE connection begins as a normal HTTP request. The server keeps the response open and sends data incrementally with the `text/event-stream` media type. Each event is represented as lines such as `event:`, `data:`, `id:`, and `retry:`, with a blank line marking the end of an event.

SSE is unidirectional: the server sends events to the client, while the client can send separate HTTP requests when it needs to communicate back. This makes SSE a natural fit for notifications, progress updates, live status changes, and streaming results where the server is the primary source of updates.

In a Java backend, an SSE endpoint can keep an HTTP response open and write events as they become available. Frameworks such as Spring provide `SseEmitter` for this pattern. The application must also consider connection cleanup, timeouts, client disconnects, concurrency, and resource usage because each active stream can remain open for a long period.

SSE clients commonly use the browser's `EventSource` API. Browsers can automatically reconnect after a connection is lost, and an event `id` can help the client tell the server which event it last received. SSE uses ordinary HTTP, so it can often work naturally with existing HTTP infrastructure, although buffering and proxy timeout behavior must be configured appropriately.

Key points

• SSE uses a long-lived HTTP response with the `text/event-stream` content type.
• Communication is primarily server-to-client; client-to-server communication uses separate HTTP requests.
• An SSE event ends with a blank line and can contain fields such as `event`, `data`, `id`, and `retry`.
• Browsers can consume SSE through the `EventSource` API and automatically reconnect after failures.
• Java applications must manage long-lived connections, disconnects, timeouts, buffering, and resource consumption.

Interview questions

What are Server-Sent Events, and when would you use them?

SSE is a mechanism for continuously delivering server-generated events to a client over a long-lived HTTP response. The response uses the `text/event-stream` content type and contains a sequence of formatted events. It is useful for notifications, progress updates, live dashboards, and other cases where the server mainly needs to push information to the client. If both sides need continuous communication, WebSockets may be more appropriate.

What does an SSE event look like on the wire?

An SSE stream consists of text lines grouped into events. Common fields include `event` for the event type, `data` for the payload, `id` for an event identifier, and `retry` for a reconnection delay. A blank line separates one event from the next. Multiple `data` lines can belong to the same event.

How does a Java backend implement SSE?

In a Spring-based Java application, an endpoint can use `SseEmitter` to keep an HTTP response open and send events over time. The application creates or obtains an emitter, registers it for later updates, and invokes its send operation whenever an event is available. Completion, timeout, and error callbacks should remove the emitter from application state. The implementation also needs to account for concurrent sends and clients that disconnect unexpectedly.

Does SSE guarantee that a client receives every event?

SSE itself is a streaming transport mechanism rather than a complete durable messaging system. A connection can fail after an event is sent or before the client has processed it, so applications requiring reliable recovery need additional state and replay logic. The `id` field and the client's reconnection information can support resuming from a known position, but the server must retain enough event history to make replay possible. Durable delivery therefore depends on the application's event storage and recovery design.

What production issues should you consider when deploying SSE?

SSE connections can remain open for a long time, so connection counts, threads or asynchronous resources, memory, and connection limits need careful management. Reverse proxies and load balancers may buffer responses or impose idle timeouts, preventing timely delivery. Heartbeats can help keep intermediary connections active, while appropriate cleanup handles disconnects and timeouts. In a distributed application, updates may also need a shared broker or other coordination mechanism so clients connected to different application instances receive the intended events.