metrics
▼Message latency
0–2 s↑
▼Empty poll requests
90%↑
██████████████░░
▼Server load
500 req/s for 1K users↑
architecture
Simple HTTP Polling
┌────────┐ GET /messages?since=T ┌────────┐
│ Client │ ─────────────────────> │ Server │
│ Alice │ <───────────────────── │ │
└────────┘ [{id:1, text:"hi"}] └────┬───┘
│ │
│ Polls every 2s ▼
└─────────────────────> ┌──────────┐
│PostgreSQL│
└──────────┘Initial architecture: clients poll for new messages every 2 seconds
story
$cdstage_q1[1/7]
# Message Delivery Protocol
Your study group loves the chat app you built over winter break. Messages arrive... eventually. Clients poll the server every 2 seconds asking "any new messages?" The server politely answers 90% of the time with "nope." Your AWS bill and your conscience both suggest a better way.
HTTP polling wastes bandwidth and adds latency. Clients ask "got messages?" every 2 seconds whether or not anyone is actually typing. The server answers thousands of empty requests. New messages arrive mid-poll, so users wait up to 2 seconds to see them. At 1,000 active users, that's 500 requests per second just to say "nothing new."
[?]
The server knows when messages arrive. What if clients opened a persistent connection and the server could push updates?
$selectstrategy↑↓ j/k enter
→Reduce polling interval to 500ms
WebSockets for persistent bidirectional connections
Server-Sent Events (SSE) for server→client push
Real-Time Chat Application|stage 1/7
▓░░░░░░14%
^→ nav|↑↓ select