Compare WebSocket, SSE, and long polling

When building real-time capabilities for a web app, the interviewer examines your networking knowledge across multiple stack layers. Treat each item below as a separate discussion. Give exact answers regarding direction, protocol, latency, and operational impact; imprecise claims like “it's faster” will be challenged.

Constraints and Assumptions

• Up-to-date evergreen browsers and a standard cloud setup with a load balancer or reverse proxy in front of stateless application servers.
• “Real-time” in this context refers to low-latency messaging either from server to client or client to server, not hard real-time guarantees.
• HTTPS is assumed throughout; TLS is mandatory.
• Consider behavior on both reliable wired networks and lossy or mobile networks as appropriate.

Questions to Clarify Beforehand

• What messaging pattern is needed: only server to client, only client to server, or fully bidirectional?
• How many concurrent connections and what per-client message rate are expected (to size connection and memory budgets)?
• Will proxies, CDNs, or corporate firewalls sit in the network path, potentially buffering responses, closing idle connections, or dropping UDP?
• Which client platforms need support (browser only, native mobile, IoT), and is there a firm backward-compatibility requirement?
• What latency and delivery-guarantee requirements exist (best-effort versus at-least-once with resume capability)?

Part 1

Comparing WebSocket with Server-Sent Events (SSE) (and mention where long polling fits). Evaluate them across: communication direction (unidirectional vs. bidirectional), transport/protocol and connection establishment, browser/client support, reconnection behavior, scalability and load-balancer/proxy impact, and typical use cases. End with a decision rule for selecting among the three options.

Hint — First establish the main axis: The most important distinguishing factor is directionality: does data flow only from server to client, or must the client also send messages? Start the comparison there before discussing transport.

Hint — How connections are established: Remember how each one begins: a WebSocket starts as an HTTP/1.1 request carrying an Upgrade: websocket handshake and then changes protocols; SSE is simply a long-lived HTTP response with Content-Type: text/event-stream. That distinction shapes how proxies and load balancers treat them.

Hint — Reconnection and operational concerns: Consider who handles reconnection (the browser's built-in EventSource versus your own client-side code) and which infrastructure adjustments are necessary: sticky sessions, idle-timeout tuning, response buffering, and a shared pub/sub fan-out mechanism when several app servers need to reach a single client.

Points This Part Should Cover

• Accurate directionality and transport for each option (full-duplex over one TCP connection versus unidirectional over standard HTTP).
• The handshake or establishment mechanism and the proxy/load-balancer implications that follow.
• Reconnection behavior (automatic EventSource reconnection using Last-Event-ID versus custom logic) and scaling issues around fan-out and sticky sessions.
• A justifiable decision rule linking each option to a use case, including when long polling is the appropriate fallback.

Part 2

The OSI model. Explain the role of each of the seven layers and provide a typical protocol or technology example for each one. Then describe how the seven-layer OSI model corresponds to the practical four-layer TCP/IP model, and why engineers usually think in terms of the latter.

Hint — Use a mnemonic and attach a protocol to each layer: Go from layer 1 to layer 7 and assign a concrete example to each (Ethernet PHY, MAC/Ethernet frames, IP, TCP/UDP, and so on). Being able to name a protocol for each layer demonstrates true understanding of that layer's function.

Hint — The mapping: The TCP/IP model reduces OSI's seven layers to four. Consider which OSI layers combine: physical with data-link, and notably session with presentation and application.

Points This Part Should Cover

• All seven layers identified with their responsibility and an appropriate example protocol or technology for each.
• A correct mapping from OSI to TCP/IP (Link layer corresponds to L1 and L2, Internet layer to L3, Transport layer to L4, Application layer to L5 through L7).
• Recognition that OSI is mainly a teaching and diagnostic framework and that actual stacks blur the boundaries (for example, where TLS fits).

Part 3

TCP versus QUIC. Compare them across: where they reside (kernel space versus user space), connection establishment / handshake latency, TLS integration, multiplexing and head-of-line blocking, connection migration, and situations where QUIC is preferred (for example, HTTP/3). Also include the trade-offs that count against QUIC.

Hint — Begin with the underlying substrate: QUIC operates over UDP in user space, whereas TCP resides in the OS kernel. Almost every benefit of QUIC (rapid iteration, built-in encryption, per-stream loss handling) stems from these two facts—so start there.

Hint — Head-of-line blocking: be precise about which layer: Head-of-line blocking occurs at two different layers. HTTP/2 eliminated application-layer HOL but still uses a single TCP connection, so losing one packet stalls every stream (transport-level HOL). Explain exactly how QUIC's per-stream architecture resolves the transport-layer problem.

Points This Part Should Cover

• The difference between user-space/UDP and kernel/TCP and its implications for deployment and iteration speed.
• A comparison of handshake latency (TCP three-way handshake plus separate TLS versus QUIC's merged transport and TLS 1.3 handshake, including 0-RTT resumption), along with the fact that TLS 1.3 is required and integrated into QUIC.
• Accurate handling of multiplexing and the transport-layer head-of-line blocking difference between HTTP/2 over TCP and HTTP/3 over QUIC.
• Connection migration using connection IDs, plus the opposing arguments such as UDP CPU overhead, middlebox or firewall blocking of UDP, and observability difficulties.

What Constitutes a Strong Answer

Throughout all three parts, a strong candidate consistently progresses from what (the mechanism or protocol) to why (latency, reliability, infrastructure compatibility) to when (a concrete use case), instead of just reciting facts. They are exact about which layer a behavior occurs at (for instance, distinguishing transport-layer from application-layer head-of-line blocking, or where TLS fits), and they bring up operational and trade-off angles—proxy/load-balancer behavior, sticky sessions and fan-out, UDP blocking, kernel versus user-space deployability—rather than only listing features.

Follow-up Questions

• For Part 1: one app server can maintain tens of thousands of WebSocket connections—how do you send a message to a user whose connection resides on a different server in the cluster?
• For Part 2: where does TLS fit in the OSI model, and why is its placement genuinely open to debate?
• For Part 3: QUIC offers 0-RTT connection resumption—what security risk does 0-RTT data create, and how is that risk mitigated?
• Across all parts: suppose a corporate firewall blocks UDP completely. Which of these technologies continue to function, and how do the client and server degrade gracefully?

Overview: This question evaluates a software engineer's depth of knowledge in web networking fundamentals, including real-time communication protocols and the OSI and TCP/IP models. It tests practical understanding of the trade-offs among WebSocket, SSE, and long polling, along with knowledge of how modern transport protocols such as QUIC differ from TCP in multiplexing, handshake latency, and connection migration.