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.

Practice

1. What is the main difference between long polling and Server-Sent Events (SSE)?

easy

A. Long polling closes the connection after each response; SSE keeps the connection open.

B. Long polling uses WebSockets; SSE uses HTTP/2 only.

C. Long polling requires client to open multiple connections; SSE uses multiple connections.

D. Long polling pushes data continuously; SSE waits for client requests.

Solution

1. Step 1: Understand long polling behavior

   Long polling keeps the HTTP request open until the server has data, then closes it after sending the response.

2. Step 2: Understand SSE behavior

   SSE keeps a single HTTP connection open to continuously push updates without closing it.

3. Final Answer:

   Long polling closes the connection after each response; SSE keeps the connection open. -> Option A

4. Quick Check:

   Connection persistence = A [OK]

Hint: Remember: long polling reconnects, SSE stays connected [OK]

Common Mistakes:

• Confusing SSE with WebSockets
• Thinking SSE uses multiple connections
• Believing long polling pushes continuously

2. Which HTTP method is typically used by clients to initiate a Server-Sent Events connection?

easy

A. POST

B. GET

C. PUT

D. DELETE

Solution

1. Step 1: Identify HTTP method for SSE

   SSE connections are initiated by clients using the GET method to request a stream from the server.

2. Step 2: Confirm other methods are not used

   POST, PUT, DELETE are used for data modification, not for opening SSE streams.

3. Final Answer:

   GET -> Option B

4. Quick Check:

   SSE connection method = GET [OK]

Hint: SSE uses GET to open a streaming connection [OK]

Common Mistakes:

• Choosing POST because it sends data
• Confusing PUT or DELETE with SSE initiation
• Thinking SSE uses WebSocket handshake methods

3. Consider this simplified server behavior for long polling:

while True:
  wait_for_event()
  send_response_to_client()
  client_reconnects()

What is the main downside of this approach compared to SSE?

medium

A. It cannot send data to multiple clients simultaneously.

B. It keeps the connection open indefinitely, wasting server resources.

C. It uses UDP instead of TCP, causing unreliable delivery.

D. It requires the client to repeatedly reconnect, causing overhead.

Solution

1. Step 1: Analyze long polling loop

   The server waits for an event, sends a response, then the client reconnects to wait again.

2. Step 2: Identify overhead caused by reconnects

   Each reconnect requires new HTTP handshake, increasing latency and server load.

3. Final Answer:

   It requires the client to repeatedly reconnect, causing overhead. -> Option D

4. Quick Check:

   Repeated reconnects = overhead [OK]

Hint: Long polling reconnects cause overhead, SSE keeps one open [OK]

Common Mistakes:

• Thinking long polling keeps connection open indefinitely
• Confusing TCP/UDP protocols in HTTP context
• Assuming long polling can't handle multiple clients

4. A developer implements SSE but notices the client stops receiving updates after some time. What is a likely cause?

medium

A. The client is not reconnecting after each message.

B. The client is sending multiple GET requests simultaneously.

C. The server is closing the connection prematurely.

D. The server is using POST instead of GET for SSE.

Solution

1. Step 1: Understand SSE connection behavior

   SSE expects the server to keep the connection open to push updates continuously.

2. Step 2: Identify issue with connection closing

   If the server closes the connection early, the client stops receiving updates until it reconnects.

3. Final Answer:

   The server is closing the connection prematurely. -> Option C

4. Quick Check:

   Connection closed early = no updates [OK]

Hint: SSE needs server to keep connection open, not close early [OK]

Common Mistakes:

• Thinking client must reconnect after every message
• Confusing HTTP methods for SSE
• Assuming multiple GET requests improve SSE

5. You are designing a chat app that must support thousands of users receiving real-time messages. Which approach is best and why?
A) Use long polling for all clients.
B) Use Server-Sent Events for all clients.
C) Use WebSockets for all clients.
D) Use HTTP polling every 5 seconds.

hard

A. WebSockets provide full-duplex communication, best for chat scalability.

B. Long polling scales well and reduces server load compared to SSE.

C. SSE keeps one connection per client open, efficiently pushing updates.

D. HTTP polling every 5 seconds is the most real-time and efficient.

Solution

1. Step 1: Evaluate long polling and SSE for scale

   Long polling causes overhead reconnects; SSE keeps connections open but is unidirectional.

2. Step 2: Consider WebSockets for chat

   WebSockets allow two-way communication with a single persistent connection, ideal for chat apps.

3. Step 3: Assess HTTP polling

   Polling every 5 seconds causes high latency and unnecessary load.

4. Final Answer:

   WebSockets provide full-duplex communication, best for chat scalability. -> Option A

5. Quick Check:

   Best real-time chat = WebSockets [OK]

Hint: Chat needs two-way, low-latency: choose WebSockets [OK]

Common Mistakes:

• Choosing SSE for two-way chat communication
• Thinking polling is efficient for real-time
• Assuming long polling scales better than WebSockets