Lesson 9 of 11 ·11 min read

1. The problem, and where push fits

HTTP is request-response: the client asks, the server answers, the connection ends. That model is perfect until the server is the one with news: a chat message arrived, the score changed, a teammate moved a card. HTTP has no native way for the server to start the conversation.

Before reaching for anything, place real-time against push notifications. They solve different halves of the same problem and serious apps use both:

A chat app runs a socket while you are in the app and falls back to FCM/APNs the moment you leave it.

2. The ladder of techniques

Like offline support, real-time is a ladder, and the bottom rungs are chronically underrated.

3. What a websocket actually is

The connection starts life as an ordinary HTTP request that asks to stop being HTTP:

GET /ws HTTP/1.1
Host: api.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols        <- the handshake succeeds
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

After the 101, the socket is no longer HTTP. The conceptual shift that follows:

-> { "type": "message.send", "temp_id": "c7a1", "room": "42", "text": "on my way" }
<- { "type": "message.ack",  "temp_id": "c7a1", "id": 4018, "ts": "..." }
<- { "type": "message.new",  "id": 4019, "room": "42", "from": "dara", "text": "grand" }

Plus heartbeats: ping/pong frames every ~30 seconds, because a silently dead connection (train tunnel, sleeping laptop) looks identical to a quiet one. No pong → close and reconnect.

4. The backend consequence: your servers become stateful

This is the section that explains why real-time is architecturally expensive.

Plain HTTP scales out easily because it is stateless: any server can answer any request, so a load balancer can spray traffic anywhere. A websocket breaks that: the live connection is pinned to one specific server's memory. When your code needs to tell user X something, it must find which server holds X's socket.

                       ┌──────────────┐
   event: "msg for     │    Redis     │   every server subscribes;
   room 42" ──publish──►   pub/sub    ├──► the one(s) holding room-42
   (from any server    │  (backplane) │    sockets deliver the frame
    or worker)         └──────────────┘

   Server A ── sockets: alice, bob        Server B ── sockets: carol
   (knows nothing of carol)               (knows nothing of alice, bob)

The standard pieces:

• A pub/sub backplane (typically Redis): servers publish events to channels; every server subscribes and delivers to whichever of its own sockets care. No server needs a global connection map.
• Connection registries / presence: knowing who is online means tracking connects and disconnects centrally, with TTLs, because servers crash without saying goodbye.
• Reconnection storms: a deploy or load-balancer blip drops 50,000 connections that all reconnect at once; backoff with jitter (client-side) and connection-rate limits (server-side) exist for this.

5. The reliability layer you must build on top

The socket will drop: phones hop between WiFi and cellular constantly. Production real-time is the raw transport plus:

1. Reconnect with exponential backoff and jitter, automatically, forever.
2. Resume: every event carries an ID; on reconnect the client says "I have up to #4017" and the server replays the gap. This is the delta-sync cursor from Offline Data & Sync wearing a different hat: a socket is just a delta feed with very low latency.
3. Persistence: messages are written to the database and pushed down sockets. The socket is a transport, not the truth. A client that missed the delivery must be able to fetch the same data over boring HTTP. (The single-source-of-truth rule, third appearance in the course.)
4. Acknowledgements client→server (so the sender's UI can show sent/delivered) and de-duplication by ID, because reconnect overlap means the same event can arrive twice.

6. Auth on a websocket

Browsers cannot set an Authorization header on a websocket connection, so bearer-token habits break. The clean pattern is a ticket:

1. Client calls a normal REST endpoint with its bearer token: POST /ws/ticket.
2. Backend returns a short-lived, single-use ticket (seconds of validity).
3. Client opens the socket with the ticket (wss://api.example.com/ws?ticket=...); the server validates it, binds the connection to the user, and the ticket dies.

Long-lived tokens directly in the query string also "work" but leak into server and proxy logs; the ticket's short life is what makes the pattern safe. Native apps can set headers on the handshake, but the ticket pattern keeps web and native clients identical. After the handshake, the connection itself is the session; re-auth on reconnect only.

7. Buy vs build

Real-time tilts further toward buy than anything else in this course, because the hard part (stateful fan-out at scale) is pure undifferentiated heavy lifting.

8. Choosing: the decision rule

Applied to the running example: the planner app needs none of this. Cache plus pull-to-refresh (rung 1) is correct, and that is a feature of the design, not a limitation.

9. Common gotchas

Reviewed 4 August 2026.