Lesson 9 of 11 ·11 min read ·Reviewed 7 August 2026

1. The problem, and where push fits

HTTP is request-response: the client asks, the server answers, the exchange 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==
Sec-WebSocket-Version: 13

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 every ~30 seconds, because a silently dead connection (train tunnel, sleeping laptop) looks identical to a quiet one. No pong → close and reconnect. (Servers use the protocol's ping frames; browser JavaScript cannot send control frames, so browser clients heartbeat with application-level messages instead.)

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 room 42"
(from any server or worker)
      │
      ▼ publish
┌─────────────────────────┐
│   Redis pub/sub         │
│   (backplane)           │
└─────────────────────────┘
      │  every server subscribes;
      ▼  room-42 holders deliver
Server A ── sockets: alice, bob
            (knows nothing of carol)
Server B ── sockets: 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. The backplane is deliberately ephemeral (at-most-once delivery; a crashed subscriber's events are gone): durable truth lives in the database, which is why the replay layer in §5 exists.
• 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, for as long as it makes sense: a network blip should never end the loop, but a fatal close code or an authentication failure must stop it.
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 and 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.
5. Flow control: bound each connection's send queue, coalesce replaceable events (cursor positions, live counters) rather than queueing every one, and disconnect chronically slow consumers. Cap message size and rate on the way in: a socket bypasses the request-size limits your HTTP middleware enforces.

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, and have a revocation story for connections that outlive their credentials (close or re-check when tokens expire, permissions change, or the account is suspended).

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 (no rung of this ladder at all) is correct, and that is a feature of the design, not a limitation.

9. Common gotchas

Reviewed 7 August 2026.