A live score ticker, a stock price feed, a notification bell that fills in without a page refresh — none of these fit the request-response model cleanly, because the client does not know when the next update will exist, only that it wants to know the instant it does. Polling on an interval wastes requests on every check that finds nothing new and still leaves a gap between the real update and the user seeing it. What the client actually wants is a connection the server can write to whenever there is something worth sending, kept open for as long as the client is watching.
Two transports offer that long-lived connection, and they are not interchangeable. Server-Sent Events keep a single HTTP request open and let the server stream events down it — strictly one direction, server to client. WebSocket performs an initial handshake and then hands both sides a full-duplex channel, where either side can send at any moment. Choosing between them by habit rather than by what the feature actually needs either overbuilds a simple feed with bidirectional machinery it will never use, or forces a genuinely interactive feature to fake two-way communication SSE was never designed to carry.
Analogy🏏Cricket
🏏 Think of it like cricket: A radio commentary box calling the ball-by-ball action to millions of listeners across the country is a one-way channel by design — the commentator describes the field placing, the bowler's approach, the shot played, and every listener receives exactly the same feed with no way to talk back through it, because none of them need to. The third umpire reviewing a tight run-out decision with the on-field umpires during a DRS review is the opposite kind of channel entirely: the on-field umpire raises the question, the third umpire replays the footage and responds, the on-field umpire asks a follow-up about a specific angle, and the conversation continues back and forth until they reach a decision together. Trying to run the DRS conversation over a one-way radio broadcast would be absurd — the on-field umpire would have no way to ask a follow-up question — and trying to run commentary to millions of listeners as a two-way conversation would be equally absurd, since nobody on the other end needs to speak back. Just as radio commentary only ever needs to flow one way, from the box to the listener, Server-Sent Events only ever need to flow one way, from the server to the client. Just as the DRS review genuinely requires both sides to speak and respond within the same live exchange, a WebSocket connection exists specifically for features where both the client and the server need to send meaningful data to each other over the same open channel. The insight is that the shape of the conversation — one voice broadcasting outward, or two parties genuinely exchanging turns — decides which channel is correct long before any question of performance or scale enters the decision.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.