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.