Art of Codeartofcode
Lesson 11 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

Sources

3 min read+10 XP

Source notes

  • APNs and FCM payload limit of 4,096 bytes: Firebase Cloud Messaging documentation ("About FCM messages", error codes); Apple Push Notification service documentation. Checked 2026-10-08.
  • SSE EventSource, the event stream format (id, event, data, retry), automatic reconnection and Last-Event-ID: HTML Living Standard and MDN "Using server-sent events". The limit of about 6 connections per browser and domain over HTTP/1.1, and negotiated streams (default 100) over HTTP/2: MDN EventSource documentation. Checked 2026-10-08.
  • WebSocket protocol: IETF RFC 6455, "The WebSocket Protocol", 2011.
  • Exponential backoff with jitter: AWS Architecture Blog, "Exponential Backoff and Jitter" (Marc Brooker, 2015).
  • Per-connection memory, connections per gateway, user counts and intervals are illustrative assumptions; measure your own stack. Arithmetic computed 2026-10-08.
  • Level 3 and Level 4 code: tested 2026-10-08 (code/ch21_realtime.py, all checks pass).