Skip to content
BytePatterns

WebSockets and Realtime

System Design: lesson 14 of 15

Keep the line open instead of redialling.

Lesson 14 of 15 · 5 min

WebSockets and Realtime

Step 1 of 11

Polling asks “anything new?” on a timer, whether or not there is news.

The Idea

Polling asks "anything new?" on a timer and mostly wastes the request. A WebSocket upgrades one HTTP connection into a channel either side can write to at any moment, so the server pushes the instant something happens. The connection is long-lived, and that is the whole design change.

Real-World Example

An air traffic control frequency stays open. Nobody redials the tower every twenty seconds to ask whether anything has changed; controller and pilot each speak when there is something to say. The cost is that the channel is occupied, and somebody has to notice when a voice goes quiet.

The Tradeoff

Every open socket is state on one particular server, which breaks the rule that makes scaling out easy — you now need sticky routing or a shared pub/sub layer to fan messages out. For updates every few seconds, plain polling or server-sent events are far less to operate.

Your turn

Put the steps in the right order.

  1. Both sides send frames whenever they have something to say
  2. The client sends an HTTP request asking to upgrade the connection
  3. The server answers 101 Switching Protocols and the socket is open
  4. A close frame, or a dropped connection, ends the session

Mini quiz

1 / 3

A WebSocket connection begins life as: