Question 1

You push live score updates one way, server to browser, to millions of clients. Clients never send data back on that channel, and you want automatic reconnect with resume. Which transport fits best?

Accepted Answer

Server-Sent Events SSE is a one way stream over plain HTTP with built in reconnect and Last-Event-ID resume, and it works through ordinary HTTP infrastructure. WebSockets work but add a bidirectional protocol you do not need and you must build reconnect and resume yourself; picking them by default is the classic mistake. Short polling wastes requests and adds up to a second of lag. Long polling costs a new request per update and is a fallback, not the first choice.

Question 2

A chat app needs low latency messages in both directions, typing indicators, and presence, on web and mobile. Which transport fits best?

Accepted Answer

WebSockets Frequent bidirectional small messages are what WebSockets are for: one long lived connection, low per message overhead. SSE plus POSTs works for occasional client sends but a POST per keystroke adds request overhead and ordering complexity. Short polling at 500 ms adds latency and load. HTTP/2 server push pushes resources into the browser cache, was never a message API, and browsers have removed it.

Question 3

Mobile clients hold a WebSocket to a notification service. Phones drop connections when switching networks. Users complain they miss notifications sent while reconnecting. What is the correct fix?

Accepted Answer

Give each message a per user sequence number, persist recent messages, and on reconnect the client sends its last seen sequence so the server replays the gap A connection is not a delivery guarantee. Anything sent while the socket is down is lost unless it is stored and replayed from a cursor. Ping intervals and TCP keepalive only detect dead connections faster; they cannot recover messages already lost. Sending twice still loses both copies if the client is offline for both, and creates duplicates otherwise.

Question 4

Your enterprise customers sit behind proxies that break WebSocket upgrades but allow normal HTTP. You need near real time order status updates, a few per minute per user. What is the pragmatic choice?

Accepted Answer

Long polling or SSE over regular HTTP Both run over standard HTTP requests and responses, so they pass through proxies that drop Upgrade, and a few updates per minute is well within their cost. Telling customers to fix their network is not a design answer. Browsers cannot open raw UDP sockets. Polling every 30 seconds misses the near real time requirement.

Question 5

A WebSocket gateway fleet of 50 nodes holds user connections. A message for user U can be produced by any backend service. How should a producer reach the node that holds U's socket?

Accepted Answer

Keep a connection registry (user to gateway node) or use a pub/sub channel per user or shard that the owning gateway subscribes to The gateway that owns the socket must be found by lookup or subscription; that decouples producers from where users are connected. Broadcasting to all nodes makes every node do 50x work and does not scale. Sticky sessions pin a client to a backend, they do nothing for a producer that is a different service. Local memory plus polling throws away the point of a push channel.

Question 6

A dashboard polls GET /status every 2 seconds. 100,000 users keep it open, and status changes about once a minute. What is the main problem with this design?

Accepted Answer

About 50,000 requests per second, almost all returning unchanged data 100,000 / 2 s = 50,000 rps, and with one change per minute around 97 percent of responses are wasted. Long polling, SSE or conditional requests fix that. Polling is plain HTTP and works fine through load balancers. GET responses can be cached and conditional (ETag), which helps but does not remove the request rate. Polling needs nothing beyond HTTP.

Question 7

Design the delivery path for real time in app notifications for 10 million daily users across web and mobile. Talk through transport, connection routing, missed messages and scale.

Accepted Answer

Transport: SSE for web if it is one way, WebSockets if the app already needs client sends; mobile uses the socket while foregrounded and APNs or FCM push when backgrounded.

Routing: gateway fleet holds connections; a registry or pub/sub keyed by user lets producers reach the owning node. Gateways are mostly stateless besides the sockets.

Missed messages: persist notifications with a per user sequence; client reconnects with last seen id and the server replays. Dedup on the client by id.

Scale: estimate concurrent connections (say 20 to 30 percent of DAU), memory per connection, use L4 or connection aware balancing, drain gateways on deploy with jittered client reconnect to avoid a thundering herd.

Follow ups: ordering, fan out for group notifications, read receipts, rate limiting noisy producers.

Polling vs SSE vs WebSockets interview questions

More networking topics

Practise these on your commute