Long polling and Server-Sent Events in HLD - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is long polling in web communication?

Long polling is a technique where the client sends a request to the server and waits for the server to respond only when new data is available, keeping the connection open for a longer time instead of immediately responding.

intermediate

How do Server-Sent Events (SSE) differ from long polling?

Server-Sent Events allow the server to push updates to the client over a single, long-lived HTTP connection without the client repeatedly requesting data, unlike long polling where the client must send new requests after each response.

intermediate

Name one advantage of using Server-Sent Events over WebSockets.

Server-Sent Events are simpler to implement for unidirectional data flow from server to client and work over standard HTTP, making them easier to use with existing infrastructure and proxies.

beginner

What happens if the server has no new data during a long polling request?

The server holds the request open until new data is available or a timeout occurs, then responds to the client. The client then immediately sends a new request to continue waiting for updates.

advanced

Why might long polling cause more server load compared to Server-Sent Events?

Because long polling requires the client to repeatedly open new HTTP connections after each response, it can create more overhead and resource usage on the server compared to a single persistent connection used by Server-Sent Events.

Which technique keeps a single HTTP connection open for continuous data flow from server to client?

A Regular polling

B Long polling

C Server-Sent Events

D FTP

Server-Sent Events use a single long-lived HTTP connection to push data continuously from server to client.

In long polling, what does the client do after receiving a response from the server?

A Closes the connection and sends a new request

B Keeps the connection open indefinitely

C Switches to WebSocket protocol

D Sends no further requests

After receiving data, the client closes the connection and immediately sends a new request to wait for more data.

Which of the following is a limitation of Server-Sent Events?

A Only supports unidirectional communication from server to client

B Requires multiple HTTP connections

C Does not work over HTTP

D Cannot handle text data

SSE supports only server-to-client data flow, not client-to-server messages.

Why might long polling be less efficient than Server-Sent Events?

A Because it requires WebSocket support

B Because it uses multiple HTTP requests and responses

C Because it uses a single persistent connection

D Because it only works with FTP

Long polling repeatedly opens and closes HTTP connections, causing more overhead than SSE's single persistent connection.

Which scenario is best suited for Server-Sent Events?

A Downloading large files

B Two-way chat application

C File upload from client to server

D Live news feed updates from server to many clients

SSE is ideal for pushing live updates from server to clients in one direction.

Explain how long polling works and describe its request-response cycle.

Think about how the client waits for data and how the server responds.

Compare Server-Sent Events and long polling in terms of connection management and data flow.

Focus on how connections are kept open and how data is sent.

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