Real-Time Delivery: Polling, Long Polling, SSE, WebSockets

Say this#

How it works#

clients <--wss--> [WS gateway nodes x N] <--subscribe--> [Redis Pub/Sub / Kafka]                        |  registry: user_id -> node_id (Redis)services --publish(user_id, event)--> broker --> node holding that socket --> client

1. Client connects (Upgrade: websocket); gateway authenticates (token in query/cookie/first frame), registers user → node in Redis with TTL, heartbeats refresh it.
2. Gateway subscribes to channels for that user (or the node subscribes once and filters locally).
3. Backend publishes message(to=user_id) to the broker; the right node receives and writes to the socket.
4. Disconnect → registry cleanup → client reconnects with backoff → missed messages fetched via API (store-and-forward) or SSE Last-Event-ID.
5. Scale by adding gateway nodes; each holds hundreds of thousands of idle connections.

Trade-offs#

Numbers#

• A tuned gateway node holds on the order of 100k-1M idle WebSocket connections (memory-bound, ~tens of KB each).
• WebSocket frame overhead: 2-14 bytes vs hundreds of bytes of HTTP headers per poll.
• Heartbeat every 20-30 s; many proxies/LBs idle-timeout at 60 s (AWS ALB default 60 s, API Gateway WS 10 min idle, 2 h max).
• Long-poll timeout ~20-30 s; SSE reconnect default 3 s.

In the interview#