Real-Time Delivery: Polling → SSE → WebSockets

15 questions

"Make it real-time" hides a ladder of escalating tradeoffs. Climb it: short polling, long polling, Server-Sent Events, and WebSockets — when each is the right tool, what they cost to scale, and the operational details that bite (reconnection with backoff, message ordering, missed-message recovery, presence, fan-out to thousands of clients, and proxy/load-balancer behavior). Grounded in the real browser APIs (EventSource, WebSocket) and Node server patterns.

Start

Questions

Not answered. Short polling vs. long polling: where does the latency go?
Not answered. What exact Content-Type makes a response an SSE stream?
Not answered. Who reconnects for you: EventSource or WebSocket?
Not answered. How can EventSource recover events missed during a disconnect?
Not answered. Why does the 7th SSE tab hang the whole app, and what removes the limit?
Not answered. Which of these are genuine reasons to choose SSE over WebSockets?
Not answered. What numeric HTTP status code confirms the protocol switch succeeded?
Not answered. What scheme does a WebSocket use when it runs over TLS?
Not answered. Why are bearer tokens awkward with native EventSource and WebSocket, and what do teams do instead?
Not answered. Do you need sequence numbers to guarantee in-order delivery on one WebSocket?
Not answered. Why does plain exponential backoff still stampede, and what fixes it?
Not answered. Why does long-polling need sticky sessions when a live WebSocket doesn't?
Not answered. What's the most likely culprit killing idle connections at ~60 seconds, and the standard fix?
Not answered. What state is the server-side connection left in, and how do heartbeats help?
Not answered. Which statements about cross-instance WebSocket fan-out are true?