Long polling and Server-Sent Events in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Difference in connection behavior between Long Polling and Server-Sent Events

Which statement correctly describes how connections behave in Long Polling compared to Server-Sent Events (SSE)?

A Long Polling repeatedly opens and closes connections, while SSE keeps a single persistent connection open.

B Both Long Polling and SSE keep multiple persistent connections open simultaneously.

C Both Long Polling and SSE repeatedly open and close connections for each message.

D Long Polling keeps a single persistent connection open, while SSE repeatedly opens and closes connections.

💡 Hint

Think about how the client waits for messages in each method.

Long Polling involves the client sending a request and the server holding it until data is available, then closing the connection. The client then immediately sends a new request. SSE keeps one connection open continuously, streaming data as it arrives.

❓ Architecture

intermediate

Choosing between Long Polling and SSE for a live sports score app

You are designing a live sports score update system for mobile and desktop browsers. Which architecture choice is best to minimize server load and provide near real-time updates?

A Use frequent short polling every second to ensure the freshest data.

B Use Long Polling because it works well with all browsers and requires no special server setup.

C Use Server-Sent Events because it maintains a single open connection per client and efficiently pushes updates.

D Use WebSockets instead of Long Polling or SSE for simpler implementation.

💡 Hint

Consider connection persistence and server resource usage.

SSE keeps one open connection per client, reducing overhead compared to Long Polling's repeated connections. Frequent short polling increases server load. WebSockets are an alternative but not part of this question.

❓ scaling

advanced

Scaling challenges with Long Polling under high user load

What is the main scaling challenge when using Long Polling for thousands of simultaneous users?

A Long Polling cannot deliver messages in order, causing data inconsistency.

B Maintaining thousands of open persistent connections consumes too much memory and file descriptors.

C Long Polling requires complex client-side logic that slows down browsers.

D Repeatedly opening and closing connections causes high CPU and network overhead on the server.

💡 Hint

Think about what happens each time a Long Polling request completes.

Long Polling repeatedly opens and closes HTTP connections, which causes CPU and network overhead. Maintaining persistent connections is a challenge for WebSockets or SSE, not Long Polling.

❓ tradeoff

advanced

Tradeoff between SSE and Long Polling for browser compatibility and server complexity

Which tradeoff best describes the choice between Server-Sent Events and Long Polling?

A Long Polling supports bidirectional communication, while SSE only supports server-to-client messages.

B Long Polling works on all browsers but increases server complexity due to repeated connections; SSE is simpler server-side but less supported.

C SSE requires complex client-side code, while Long Polling uses simple JavaScript APIs.

D SSE has better browser support but requires more server resources than Long Polling.

💡 Hint

Consider browser support and server resource usage.

Long Polling works on all browsers but causes repeated connection overhead. SSE is simpler on the server side with a single connection but has limited support on older browsers. SSE is unidirectional; bidirectional requires WebSockets.

❓ estimation

expert

Estimating server resource usage for 10,000 SSE clients

You plan to support 10,000 simultaneous clients using Server-Sent Events. Each client keeps one open HTTP connection. Estimate the main server resource bottleneck and the best approach to handle it.

A Memory and file descriptors will be the bottleneck; use an event-driven server and increase OS limits for open files.

B CPU usage will be the bottleneck; use more powerful CPUs to handle message encoding.

C Network bandwidth will be the bottleneck; compress all messages aggressively to reduce size.

D Disk I/O will be the bottleneck; cache messages on disk to reduce memory usage.

💡 Hint

Think about what keeping many open connections requires from the operating system.

Each open connection uses memory and a file descriptor. Handling 10,000 connections requires an event-driven server model and increasing OS limits for open files. CPU and network are important but less critical bottlenecks here.