Question presented to candidate: "Our app needs to show fresh data without the user pressing refresh. You could poll, long-poll, use Server-Sent Events or open a WebSocket. How do they differ, and how would you pick one for, say, a live sports score page versus a chat app?"
What a strong answer should cover:
- How each works: short polling (ask on a timer), long polling (server holds the request until there is news), SSE (one HTTP response that never ends, server to client only), WebSocket (an upgraded connection carrying messages both ways)
- The cost model: polling trades latency against empty requests; push transports trade request load for long-lived connections that the server and every proxy must hold
- SSE details that matter: plain HTTP, built-in reconnect with Last-Event-ID, text only, the 6-connection-per-domain limit over HTTP/1.1 that HTTP/2 removes
- WebSocket details: HTTP Upgrade handshake (RFC 6455), tiny frame overhead, binary support, no built-in reconnect or resume, idle timeouts at load balancers
- A decision rule tied to the product: update frequency, direction of data, client count, and infrastructure (proxies, serverless, mobile battery)
Clarifying questions expected:
- How often does the data change, and how stale may the screen be?
- Does the client need to send frequent messages back, or only receive?
- How many clients are connected at once, and what sits between them and the servers (CDN, corporate proxies, a serverless platform)?
Code / implementation expected: Optional โ a clear comparison and a reasoned choice; the example simulates all four on the same minute of events.