Long polling and Server-Sent Events in HLD - System Design Guide

Problem Statement

Traditional HTTP requests require the client to repeatedly ask the server for updates, causing delays and unnecessary network traffic. Without a mechanism to push real-time data, users experience slow updates and inefficient resource use, especially in chat apps or live feeds.

Solution

Long polling keeps the client request open until the server has new data, then responds immediately, reducing delay. Server-Sent Events (SSE) establish a persistent connection where the server continuously pushes updates to the client as they happen, enabling efficient real-time communication.

Architecture

Client

↓

Client

The diagram shows two flows: long polling where the client sends a request and waits until the server responds with data, then repeats; and Server-Sent Events where the client opens a persistent connection and the server pushes updates continuously.

Trade-offs

✓ Pros

→

Long polling reduces latency compared to frequent polling by holding requests open until data is available.

→

SSE provides a simple, lightweight way to push real-time updates over HTTP without complex protocols.

→

Both methods work well with existing HTTP infrastructure and proxies without special support.

✗ Cons

→

Long polling can cause higher server load due to many open connections waiting for data.

→

SSE is unidirectional (server to client) and not supported in all browsers, limiting use cases.

→

Neither method is ideal for very high-frequency or bidirectional communication compared to WebSockets.

Use long polling or SSE when you need real-time updates with moderate frequency and mostly server-to-client communication, especially when WebSocket support is limited or infrastructure constraints exist.

Avoid these methods when your system requires low-latency, bidirectional communication at very high scale (e.g., gaming or trading platforms), where WebSockets or other protocols are more suitable.

Real World Examples

Twitter

Uses long polling to deliver new tweets and notifications in near real-time when WebSocket support is limited.

GitHub

Uses Server-Sent Events to push live updates about repository events and notifications to users.

Slack

Uses long polling as a fallback mechanism for real-time messaging when WebSocket connections are blocked.

Alternatives

WebSockets

Provides full-duplex, bidirectional communication over a single persistent connection.

Use when: Use when you need low-latency, bidirectional communication with high message frequency.

Polling

Client repeatedly sends requests at fixed intervals regardless of data availability.

Use when: Use for simple or low-frequency update needs where server push is not required.

Summary

Long polling and Server-Sent Events enable servers to push real-time updates to clients efficiently over HTTP.

Long polling keeps client requests open until new data is ready, reducing delay compared to frequent polling.

Server-Sent Events maintain a persistent connection for continuous server-to-client event streaming.

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