WebSockets and push
A connection that stays open.
A chat app needs messages to appear within a fraction of a second, in both directions, and users also want typing indicators and read receipts. Polling is too slow, and SSE only carries data one way. A WebSocket starts as an ordinary HTTP request that asks to upgrade. If the server agrees, the connection stays open and turns into a two-way channel where either side can send small messages at any time, with very little overhead per message.
Life of a WebSocket connection
Step 1 of 5
Handshake
The browser sends an HTTP request with an Upgrade header. The server answers 101 Switching Protocols, and from then on the same TCP connection carries WebSocket frames, not HTTP.
The trade is clear. WebSockets give low latency and efficient two-way traffic, but you take on state: each connected client is a live object on one specific server. That makes deployment, load balancing and failure handling harder than for stateless request handlers. A server restart disconnects everyone on it, and all those clients try to reconnect at once.
Your turn
List two reasons a team might choose SSE over WebSockets for order-status updates, and one reason they would need WebSockets for the chat feature.
Stuck? Direction of traffic and operational simplicity.
What to remember
A WebSocket upgrades an HTTP request into a persistent two-way channel.
It gives low latency and low per-message overhead.
Each connection is state held on one server, which complicates scaling.
Use it when updates are frequent or two-way; otherwise polling or SSE may do.