Practice the vocabulary of a simple, one-way, server-pushed stream of updates over a single HTTP connection.
0 / 5 completed
1 / 5
At standup, a dev mentions a server pushing a continuous stream of one-way text updates to a browser over a single long-lived HTTP connection, without the client needing to poll repeatedly. What technology is being described?
Server-Sent Events, or SSE, push a continuous stream of one-way text updates from the server to a browser over a single long-lived HTTP connection, without the client needing to poll repeatedly for new data. Repeatedly polling on a fixed interval wastes requests when there's nothing new to report and adds latency between an update happening and the client actually noticing it. This long-lived, server-pushed stream is what makes SSE a simpler alternative to polling for a one-way update feed.
2 / 5
During a design review, the team wants a client's EventSource to reconnect automatically and resume from the last event it received if the SSE connection drops. Which capability supports this?
Automatic reconnection with a Last-Event-ID lets a client's EventSource reconnect on its own and resume from the last event it actually received if the SSE connection drops. Requiring a manual page reload after a dropped connection loses that continuity and interrupts the user's experience unnecessarily. This automatic, resumable reconnection is a built-in behavior of the EventSource API that makes SSE more resilient than it might first appear for a simple one-way stream.
3 / 5
In a code review, a dev notices the team chose SSE over WebSockets for a notification feed because the server only ever needs to push updates to the client, with no need for the client to send a message back over the same connection. What does this represent?
Choosing a one-way streaming protocol appropriate to a one-way data flow means picking SSE, which is simpler to implement and works over plain HTTP, when the server only ever needs to push updates with no client-to-server message required on that same connection. Choosing WebSockets regardless of that need adds bidirectional complexity a purely one-way feed doesn't actually require. This matching of protocol to actual data-flow shape is a sound default when deciding between SSE and WebSockets for a given feature.
4 / 5
An incident report shows a notification feed built on repeated short polling generated a large, unnecessary volume of requests during a quiet period with no actual updates, driving up server load for little benefit. What practice would prevent this?
Replacing the repeated polling with Server-Sent Events means the server only sends data over the long-lived connection when there's an actual update to report, rather than the client repeatedly asking whether anything changed. Continuing to poll on a fixed interval regardless of actual update frequency is exactly what generated the unnecessary request volume this incident describes. This switch to an event-driven, server-pushed stream is a standard fix for reducing polling-driven server load on a low-frequency update feed.
5 / 5
During a PR review, a teammate asks why the team uses Server-Sent Events for a one-way notification feed instead of a full WebSocket connection. What is the reasoning?
A WebSocket adds bidirectional complexity that a purely one-way feed doesn't actually need, since the client never has to send a message back over that same connection. SSE stays simpler, works over plain HTTP, and includes automatic, resumable reconnection built directly into the browser's EventSource API. The tradeoff is that SSE is strictly one-way, so a feature that later needs the client to send data back over the same connection would require switching to WebSockets instead.