SSE Last-Event-ID

SSE clients can identify the last event they successfully received when reconnecting, allowing a server to resume delivery from an appropriate position. The mechanism uses event IDs and the HTTP `Last-Event-ID` request header.

In Server-Sent Events, a server can attach an identifier to an event with the SSE `id:` field. The client tracks the most recently received event ID and, when its connection is re-established, an SSE-capable client can send that value in the `Last-Event-ID` HTTP request header.

The server can use this identifier as a resume cursor. For example, if the client reports `42`, the server might replay events after ID 42 from a retained event log before continuing with new events. The exact replay strategy is application-specific; SSE itself does not provide durable event storage.

A useful distinction is that the event ID is part of the SSE stream, while `Last-Event-ID` is metadata on the subsequent HTTP request. The server must therefore maintain enough history or another mapping mechanism to determine what should be replayed.

If the server cannot retain or reconstruct events that precede the current stream position, it cannot guarantee lossless recovery merely because `Last-Event-ID` was supplied. Production systems commonly combine the ID with a durable log, bounded replay window, or an explicit resynchronization path.

Key points

• The SSE `id:` field establishes the event identifier tracked by the client.
• After reconnecting, the client can send the identifier using `Last-Event-ID`.
• The server decides how to interpret the ID and which events to replay.
• Reliable recovery requires the server to retain or reconstruct relevant event history.
• Event IDs should be designed as stable resume cursors, not merely display labels.

Interview questions

What is the difference between the SSE `id:` field and the `Last-Event-ID` header?

The `id:` field is part of an SSE event sent from server to client. The client records the latest applicable event ID and can send that value back in `Last-Event-ID` when reconnecting. Thus, one establishes the stream position and the other communicates the previously received position back to the server. They participate in the same resume mechanism but occur in opposite directions.

What is the purpose of `Last-Event-ID` in Server-Sent Events?

It lets an SSE client tell the server which event it most recently received when reconnecting. The value corresponds to an event identifier supplied by the server in the stream. The server can then use it to determine where to resume delivery. Successful replay depends on the server having the required event history.

How does an SSE server use an event ID to resume a disconnected client?

The server receives the client's last processed event ID and treats it as a resume cursor. It can query retained events and send those whose IDs follow that cursor. After replay, it can continue streaming newly generated events. The application must define what happens when the cursor is invalid, expired, or outside the retained history.

What would you do if the requested `Last-Event-ID` is no longer available?

I would make the behavior explicit rather than silently pretending the stream can resume exactly. If the application can reconstruct state, I might send a fresh snapshot followed by events from a current position. Another option is to reject or restart the stream with an application-specific resynchronization response. The correct choice depends on whether the client needs exact event history or only a current consistent state.

What properties should SSE event IDs have in a distributed Java backend?

They should provide a stable ordering or cursor semantics appropriate to the event store. A single monotonically increasing number is simple when one ordered source exists, but distributed systems may require IDs tied to a partition and offset or another durable position. The ID should remain meaningful across reconnects and should not depend on ephemeral server memory. The design also needs to define duplicate handling and replay boundaries.