Messaging
Part 1 of 6 · WebSockets & MQTTWebSockets & MQTT — Real-Time Protocols for Senior Interviews
Interviewers ask how you push live updates without burning sockets, batteries, or ops. WebSockets give full-duplex browser streams; MQTT gives topic-based pub/sub for devices. SSE, long-polling, and Kafka-style logs fill different niches — this hub maps the cluster.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
How you push live updates
Prefer
Match protocol to direction, client, and durability
Bidirectional browser UI → WebSocket. Server-to-client dashboards → SSE. Constrained devices and topic routing → MQTT. Audit, replay, and stream processing → a durable log. Hostile proxies → long-poll as a last resort.
- WebSocket is connection-oriented; scale with sticky or a shared bus.
- MQTT is broker-centric: QoS, retained, sessions, and LWT are built-in.
- Kafka is not a browser push API — bridge high-value events into the log.
Alternative
Always WebSocket, or MQTT QoS 2 as exactly-once
Looks decisive on a whiteboard. Proxies, battery, one-way UIs, and topic ACLs punish a single-protocol default. QoS 2 is hop-scoped; Kafka EOS is a produce/consume pipeline.
- Socket.IO is not raw WebSocket — fallbacks and custom framing change the load test.
- Sticky without a fan-out bus cannot push to sockets on another node.
- Long-polling without jitter becomes a reconnect storm after deploys.
Failure path this cluster exists to name
Each hop is a later lesson. Interviews start at the stuck socket and the wrong protocol, not at library trivia.
- 1
Pick a push channel
Direction, client, proxy, battery, topic ACL. Depth: the choice matrix. - 2
Upgrade or CONNECT
WS is HTTP 101 plus Accept. MQTT is CONNECT plus session. Depth: handshake and MQTT essentials. - 3
Pin the live connection
The socket lives on one process. Without affinity or a bus, the next node cannot write frames. Depth: scaling + sticky sessions. - 4
Treat QoS 2 as Kafka EOS
Different scopes. MQTT is broker-to-client; Kafka EOS is the log pipeline. Depth: MQTT essentials, then Kafka delivery. - 5
Drain, ACL, LWT, bridge
Close 1001 on deploy. Namespace topics. Fire last-will on unclean disconnect. Bridge high-value events — do not loop prefixes. Depth: scaling and brokers.
Overview
Interview prompt: how do you push live updates to browsers and devices? Seniors are graded on protocol choice and failure modes — idle proxies, sticky sockets, QoS vs log semantics — not on Socket.IO trivia.
WebSockets give full-duplex streams after an HTTP upgrade. MQTT gives hierarchical pub/sub through a broker, with QoS, retained messages, and sessions. SSE is server-to-client over HTTP with auto-reconnect. Long-polling is the fallback when middleboxes strip upgrades. A Kafka-style log is durable ordered storage with consumer groups — not a browser push protocol.
This hub is the map. The five sibling pages are the whiteboard depth. Kafka delivery already lives in topics / partitions and ALO / AMO / EOS.
You should be able to:
- Draw browser → L7 LB → WS workers + Redis fan-out, and device → MQTT broker, with an optional Kafka persist hop.
- Say when you would refuse WebSocket (one-way UI, battery-bound MCU, topic ACL as the product).
- Contrast sticky sockets vs a fan-out bus in one sentence — without re-teaching L4 vs L7 or Kafka ISR.
Where each protocol fits
| Protocol | Wins | Loses |
|---|---|---|
| WebSocket | Browser/app bidirectional chat, collab, trading ticks | Connection-oriented; sticky or shared state at scale; proxy idle timeouts |
| MQTT | IoT/telemetry, mobile presence, fan-out by topic | Another moving part (the broker); hop-scoped QoS |
| SSE | Simple dashboards; EventSource retries + Last-Event-ID | Unidirectional; HTTP/1.1 connection caps |
| Long-polling | Works when proxies strip Upgrade | Latency floor = poll interval; reconnect herds |
| Kafka (existing cluster) | Durable ordered log, consumer groups, replay | Not a browser push API — bridge, do not replace |
Rule of thumb: browser UI live updates → WebSocket or SSE; constrained devices / topic routing → MQTT; audit/replay / stream processing → Kafka.
Depth: handshake, MQTT essentials, choice matrix.
Architecture (two edges)
Browser traffic upgrades at an L7 load balancer, then lives on a WS worker. Device traffic CONNECTs to a broker. Both may bridge high-value events into a durable log. Split the paths so the desktop SVG stays a single column.
WebSocket edge — affinity or reconnect, then a bus if rooms span nodes:
Flow
- 1
1 Browser
- next2 L7 LB sticky or anycast
- 2
2 L7 LB sticky or anycast
- next3 WS worker plus Redis bus
- 3
3 WS worker plus Redis bus
- next4 Fan-out room events
- 4
4 Fan-out room events
- next5 Optional Kafka persist
- 5
5 Optional Kafka persist
- next6 Drain: close 1001 then reconnect
- 6
6 Drain: close 1001 then reconnect
Lesson map
WebSockets & MQTT — Real-Time Protocols for Senior Interviews
Interviewers ask how you push live updates without burning sockets, batteries, or ops. WebSockets give full-duplex browser streams; MQTT gives topic-based pub/sub for devices. SSE, long-polling, and Kafka-style logs fill different niches — this hub maps the cluster.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB b["1 Browser"] lb["2 L7 LB sticky or anycast"] ws["3 WS worker plus Redis bus"] peer["4 Fan-out room events"] b -->|1 Browser to 2 L7 LB sticky or anycast| lb lb -->|2 L7 LB sticky or anycast| ws ws -->|3 WS worker plus Redis bus| peer
MQTT edge — CONNECT, subscribe, hop-scoped QoS:
Flow
- 1
1 Device MQTT client
- next2 MQTT broker cluster
- 2
2 MQTT broker cluster
- next3 Topic fan-out with QoS
- 3
3 Topic fan-out with QoS
- next4 Optional Kafka bridge
- 4
4 Optional Kafka bridge
Sticky vs stateless for HTTP APIs is the LB sticky lesson. Protocol awareness at the edge is L4 vs L7. The load-balancing hub owns VIP, health, and drain — this cluster deepens the long-lived socket, it does not recap algorithms.
Sandbox: protocol picker (Python)
Educational chooser. Durable replay without a browser points at Kafka (see the existing delivery docs). Topic routing plus battery or non-browser points at MQTT.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Same idea (TypeScript)
Press Run. Snippets must be self-contained — no network, files, or native modules.
Cluster map
| Order | Page | You defend |
|---|---|---|
| 1 | This hub | Protocol map; Kafka is a cousin log, not a push API |
| 2 | Handshake, frames, ping/pong | 101 + Accept, opcodes, keepalive vs TCP keepalive, close 1001/1006 |
| 3 | MQTT essentials | Topics, wildcards, QoS 0/1/2, retained, sessions |
| 4 | Choice matrix | When to choose what; MQTT-over-WS; anti-patterns |
| 5 | Scaling WebSockets | Sticky, Redis fan-out, backpressure |
| 6 | Brokers, ACL, LWT, bridging | Tenancy, last will, prefix-safe bridges |
Pitfalls
A trading desk wants live ticks in the browser and later wants IoT sensors plus 30-day replay. Which protocol starts the UI? When do you add MQTT? When do you bridge to Kafka rather than stretching MQTT QoS 2? Now add a corporate proxy that strips Upgrade — what is the fallback, and what tax do you accept?
Interview Q&A
Why not always WebSocket?
Answer
Proxies that strip Upgrade, battery-sensitive devices, one-way UIs, and topic ACLs often favor SSE or MQTT. WebSocket is the right default for bidirectional browser apps — not a universal transport.
WebSocket vs MQTT for mobile chat?
Answer
WebSocket for rich media UIs in the app. MQTT when presence, topic routing, and intermittent networks dominate. Many mobile chats use MQTT under the hood for presence and still speak WebSocket to the browser.
Where does Kafka sit?
Answer
Durable log plus consumer groups and replay. Bridge from WebSocket or MQTT for analytics and audit. It is not a browser push protocol. Depth: Kafka topics and delivery semantics.
Why sticky for WebSockets?
Answer
The connection lives on one node. Without shared pub/sub, other nodes cannot push to that socket. Affinity reduces reconnect churn; room and presence state still need a bus for failover. Depth: sticky sessions and scaling.
MQTT QoS 2 vs Kafka exactly-once?
Answer
Different scopes. MQTT QoS is broker-to-client on that hop. Kafka EOS is a produce/consume pipeline with idempotent producers and transactions. Do not equate them. Cross-link Kafka delivery; do not re-teach acks here.
Does SSE auto-reconnect?
Answer
EventSource retries. Last-Event-ID resumes the stream. It is still unidirectional — client-to-server stays on HTTP POST or a second channel.
When long-polling?
Answer
Corporate proxies that strip Upgrade, or ancient stacks that cannot stream. Accept the latency tax (at least one poll interval) and jitter timeouts so deploys do not thundering-herd.
What is LWT for?
Answer
Last Will and Testament: the broker publishes a death notice on unclean disconnect. Presence without client heartbeat storms. Depth: brokers.
Can L4 terminate WebSocket?
Answer
L4 can pass TCP. Path-based routing, cookie auth, and protocol-aware idle timeouts usually need L7. Depth: L4 vs L7 proxies.
Is Socket.IO the same as WebSocket?
Answer
No. Socket.IO may start with polling, then upgrade, and uses its own packet framing. Load-test the real stack. Depth: handshake.
MQTT in the browser?
Answer
Browsers lack raw MQTT TCP. Use MQTT-over-WebSocket to the broker. You still get topics and QoS; you still inherit WebSocket scaling at the edge. Depth: choice matrix.
How do you drain WebSocket workers on deploy?
Answer
Send close 1001 (going away), drain, let clients reconnect with backoff to healthy nodes. Align ping interval to be shorter than LB idle timeout. Depth: handshake and health / drain.