Art of Codeartofcode
Lesson 2 of 12

21. Polling vs WebSockets vs Push

1
The picture to keep in your head
2
21.1 What's the problem: the server has news for you?
3
21.2 What are the options?
4
21.3 How do you scale millions of open connections?
5
21.4 How do heartbeats, reconnects and missed messages work?
6
21.5 How do you choose?
7
Memory card and where the analogy breaks
8
Practice: five levels
9
Interview questions
10
Solutions
11
Sources
12
Code lab
21. Polling vs WebSockets vs Push

21.1 What's the problem: the server has news for you?

3 min read+10 XP

At the gate: The shop knows the moment your order is packed. You don't. And the shop can't just ring your doorbell: it doesn't know if you're home, and it doesn't have a direct line to you unless you've left one open.

In the system: Plain HTTP is request-response: the client asks, the server answers, the exchange ends. The server can't start a conversation. That's fine for "show me my orders", but not for:

  • "Your order is packed" (order tracking).
  • A new chat message (Chapter 38).
  • A live score or a price change.
  • A rider moving on the map every few seconds.

The server can't simply open a connection to your phone either: phones and browsers sit behind home routers, mobile networks and firewalls that block incoming connections. So every option in this chapter starts with the client connecting to the server, and differs in what happens next.

What we care about when choosing:

  • Latency: how quickly does the news arrive?
  • Waste: how many requests come back empty?
  • Server cost: how many connections are held open, and for how long?
  • Direction: server to client only, or both ways?
  • Reach: does it work when the app is closed?

Memory code: "The server knows first, but only the client can dial."