System Design (HLD)Long Polling

Long Polling: The Art of Simulated Real-Time

LevelIntermediate

Duration55 mins

TopicLong Polling

4 / 5

Comparison with Other Approaches

Choosing the Right Real-Time Technology

Long polling is one of several technologies available for real-time communication. WebSockets, Server-Sent Events (SSE), and even simple short polling each have distinct characteristics that make them optimal for different scenarios.

The choice between these technologies is rarely obvious. Each has scenarios where it shines and scenarios where it struggles. Understanding these trade-offs in depth is essential for making architecture decisions that will scale with your product.

In this page, we'll conduct a rigorous comparison across multiple dimensions: connection model, latency profile, scalability characteristics, infrastructure requirements, and failure modes. By the end, you'll have a decision framework for selecting the right technology for any real-time requirement.

What You Will Learn

By the end of this page, you'll understand the fundamental differences between long polling, WebSockets, SSE, and short polling. You'll be able to articulate the trade-offs of each approach and select the appropriate technology for specific use cases based on technical constraints and requirements.

Technology Overview

Before comparing, let's establish clear definitions of each technology and their fundamental operating models.

The Four Real-Time Approaches:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
1. SHORT POLLING
═════════════════════════════════════════════════════════════════
 
Client                                              Server
   │                                                   │
   │────── Request ──────────────────────────────────▶│
   │                                                   │──┐ Immediate
   │◀───── Response (data or empty) ──────────────────│◀─┘ Response
   │                                                   │
   │  [Wait interval: 1-60 seconds]                    │
   │                                                   │
   │────── Request ──────────────────────────────────▶│
   │◀───── Response ─────────────────────────────────│
   │                                                   │
   ▼                                                   ▼
 
2. LONG POLLING
═════════════════════════════════════════════════════════════════
 
Client                                              Server
   │                                                   │
   │────── Request ──────────────────────────────────▶│
   │                                                   │
   │        [Connection held open 30-60 seconds]       │
   │                                                   │
   │◀───── Response (when data available OR timeout) ─│
   │                                                   │
   │────── Immediate Reconnect ──────────────────────▶│
   │        [Wait for next event...]                   │
   │                                                   │
   ▼                                                   ▼
 
3. SERVER-SENT EVENTS (SSE)
═════════════════════════════════════════════════════════════════
 
Client                                              Server
   │                                                   │
   │────── Request (Accept: text/event-stream) ──────▶│
   │                                                   │
   │◀───── Event 1 ─────────────────────────────────│
   │       (same connection)                           │
   │◀───── Event 2 ─────────────────────────────────│
   │       (same connection)                           │
   │◀───── Event 3 ─────────────────────────────────│
   │       ...                                         │
   │◀───── Event N ─────────────────────────────────│
   │                                                   │
   ▼                     Persistent Connection         ▼
 
4. WEBSOCKETS
═════════════════════════════════════════════════════════════════
 
Client                                              Server
   │                                                   │
   │────── HTTP Upgrade Request ─────────────────────▶│
   │◀───── 101 Switching Protocols ──────────────────│
   │                                                   │
   │◀═══════════════ Full Duplex ═══════════════════▶│
   │                                                   │
   │────── Client Message 1 ─────────────────────────▶│
   │◀───── Server Message 1 ─────────────────────────│
   │◀───── Server Message 2 ─────────────────────────│
   │────── Client Message 2 ─────────────────────────▶│
   │                                                   │
   ▼              Bidirectional Persistent             ▼

Fundamental Characteristics
Characteristic	Short Polling	Long Polling	SSE	WebSocket
Connection Type	New per request	New per event batch	Persistent	Persistent
Direction	Client → Server	Client → Server	Server → Client	Bidirectional
Protocol	HTTP	HTTP	HTTP (streaming)	WS (upgrade from HTTP)
Browser Support	Universal	Universal	All modern (not IE)	All modern
Proxy Compatibility	Excellent	Good	Moderate	Variable

Latency and Performance Comparison

Latency characteristics vary significantly across technologies. The right choice depends on your latency requirements and how you define "real-time."

Theoretical Latency Analysis:

Latency Characteristics (Typical Network Conditions)
Metric	Short Poll (5s)	Long Poll	SSE	WebSocket
Best Case Latency	~50ms (poll hit)	~50ms	~20ms	~10ms
Average Latency	~2.5s (half interval)	~100-200ms	~40ms	~20ms
Worst Case Latency	~5s (full interval)	~500ms	~100ms	~50ms
Connection Setup	~0ms (persistent HTTP)	~0ms	~100ms (initial)	~150ms (upgrade)
Recovery Time	~5s (next poll)	~100ms (reconnect)	~1-3s (auto)	~1-3s (reconnect)

Understanding the Latency Components:

Short Polling Latency:

Events can only be delivered when the poll occurs
Average wait = interval / 2 (e.g., 2.5s for 5s interval)
Decreasing interval reduces latency but increases server load exponentially

Long Polling Latency:

Event delivered as soon as available (~50ms network delay)
Reconnection gap between requests (~50-100ms)
Occasional timeout cycle adds ~0ms (just reconnects)

SSE Latency:

Persistent connection = no reconnection delay
Event buffering in server/proxy may add ~10-50ms
Browser's EventSource API adds minimal overhead

WebSocket Latency:

Lowest possible latency = network round-trip only
No HTTP overhead on established connection
Binary framing more efficient than text-based HTTP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
// Measure end-to-end latency for each technology
 
async function measureLatency() {
    const results = {
        shortPoll: await measureShortPoll(),
        longPoll: await measureLongPoll(),
        sse: await measureSSE(),
        websocket: await measureWebSocket(),
    };
    
    return results;
}
 
async function measureShortPoll(): Promise<LatencyMetrics> {
    const samples: number[] = [];
    
    // Server triggers event at random times
    // Client polls every 2 seconds
    for (let i = 0; i < 100; i++) {
        const eventTime = await triggerServerEvent();
        
        let receivedTime = 0;
        while (true) {
            const response = await fetch('/api/poll');
            const data = await response.json();
            
            if (data.events.find(e => e.timestamp === eventTime)) {
                receivedTime = Date.now();
                break;
            }
            
            await sleep(2000); // Poll interval
        }
        
        samples.push(receivedTime - eventTime);
    }
    
    return computeMetrics(samples);
}
 
async function measureLongPoll(): Promise<LatencyMetrics> {
    const samples: number[] = [];
    
    for (let i = 0; i < 100; i++) {
        const eventTime = await triggerServerEvent();
        
        const response = await fetch('/api/long-poll');
        const receivedTime = Date.now();
        const data = await response.json();
        
        if (data.events.length > 0) {
            samples.push(receivedTime - eventTime);
        }
    }
    
    return computeMetrics(samples);
}
 
async function measureSSE(): Promise<LatencyMetrics> {
    return new Promise((resolve) => {
        const samples: number[] = [];
        let eventTimes: Map<string, number> = new Map();
        
        const es = new EventSource('/api/events');
        
        es.onmessage = (event) => {
            const receivedTime = Date.now();
            const data = JSON.parse(event.data);
            const eventTime = eventTimes.get(data.id);
            
            if (eventTime) {
                samples.push(receivedTime - eventTime);
                eventTimes.delete(data.id);
                
                if (samples.length >= 100) {
                    es.close();
                    resolve(computeMetrics(samples));
                }
            }
        };
        
        // Trigger events
        (async () => {
            for (let i = 0; i < 100; i++) {
                const eventId = await triggerServerEvent();
                eventTimes.set(eventId, Date.now());
                await sleep(100);
            }
        })();
    });
}
 
async function measureWebSocket(): Promise<LatencyMetrics> {
    return new Promise((resolve) => {
        const samples: number[] = [];
        
        const ws = new WebSocket('/api/ws');
        
        ws.onmessage = (event) => {
            const receivedTime = Date.now();
            const data = JSON.parse(event.data);
            samples.push(receivedTime - data.serverTime);
            
            if (samples.length >= 100) {
                ws.close();
                resolve(computeMetrics(samples));
            }
        };
        
        ws.onopen = async () => {
            for (let i = 0; i < 100; i++) {
                await triggerServerEvent();
                await sleep(100);
            }
        };
    });
}

Latency vs Perceived Latency

Technical latency doesn't always equal perceived latency. Users don't notice 50ms vs 200ms for most applications. The threshold for 'instant' is ~300ms. All four technologies can achieve this for typical use cases. Choose based on other factors unless sub-100ms latency is genuinely required.

Resource Consumption Analysis

Different technologies consume server resources differently. Understanding these patterns is critical for capacity planning.

Resource Consumption by Technology:

Resource Consumption Patterns (per 10,000 connected clients)
Resource	Short Poll (5s)	Long Poll	SSE	WebSocket
HTTP Requests/second	2,000	~50*	Initial only	Initial only
TCP Connections	~100 (pooled)	10,000	10,000	10,000
Memory per client	~0 (stateless)	~1KB	~1KB	~2KB
CPU (idle)	High (processing)	Low	Very Low	Very Low
CPU (event burst)	High	Moderate	Low	Very Low
Bandwidth overhead	Very High	Low	Very Low	Lowest

*Long poll requests per second depends on event frequency. With 1 event per client per minute average, only ~170 requests/second (reconnections).

Detailed Resource Analysis:

Short Polling:

High request volume = high CPU for request processing
Each request incurs HTTP parsing, routing, authentication
Stateless = no memory for waiting clients, but...
Database/cache hit on every poll, even when empty
Bandwidth: Full HTTP headers on every request/response

Long Polling:

Request volume = event volume + timeout reconnections
Memory: Must track each waiting request
CPU: Minimal while waiting, spikes during event delivery
Network: Efficient—responses only when data exists

SSE:

Persistent connection = one-time request overhead
Memory: Connection state + event buffer
CPU: Very low—just format events in text/event-stream
Limitation: Unidirectional limits use cases

WebSocket:

Most efficient at steady-state
Higher initial handshake cost
Memory: Per-connection state + frame buffers
CPU: Frame encoding/decoding, ping/pong keep-alive

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
// Calculate server resources needed for 1 million connected users
 
interface ResourceEstimate {
    servers: number;        // 8-core, 32GB servers
    monthlyBandwidth: number; // GB
    monthlyCost: number;    // USD (estimated)
}
 
function estimateShortPolling(
    users: number,
    pollInterval: number,  // seconds
    avgEventSize: number   // bytes
): ResourceEstimate {
    const requestsPerSecond = users / pollInterval;
    const httpOverhead = 500; // bytes per request/response
    const hitRate = 0.01;     // 1% of polls return data
    
    // CPU: ~5000 req/s per core for simple handlers
    const coresNeeded = requestsPerSecond / 5000;
    const servers = Math.ceil(coresNeeded / 8);
    
    // Bandwidth
    const requestsPerMonth = requestsPerSecond * 60 * 60 * 24 * 30;
    const bytesPerRequest = httpOverhead + (avgEventSize * hitRate);
    const monthlyBandwidth = (requestsPerMonth * bytesPerRequest) / 1e9;
    
    return {
        servers,
        monthlyBandwidth,
        monthlyCost: servers * 500 + monthlyBandwidth * 0.05,
    };
}
 
function estimateLongPolling(
    users: number,
    avgEventsPerHour: number,
    avgEventSize: number
): ResourceEstimate {
    // Reconnections: timeout every 30s + after each event
    const timeoutReconnectsPerHour = users * (3600 / 30);
    const eventReconnectsPerHour = users * avgEventsPerHour;
    const totalRequestsPerHour = timeoutReconnectsPerHour + eventReconnectsPerHour;
    
    const requestsPerSecond = totalRequestsPerHour / 3600;
    const coresNeeded = requestsPerSecond / 5000;
    
    // Memory: 1KB per waiting connection
    const memoryGB = (users * 1024) / 1e9;
    const serversForMemory = Math.ceil(memoryGB / 28); // 28GB usable
    const serversForCPU = Math.ceil(coresNeeded / 8);
    const servers = Math.max(serversForMemory, serversForCPU);
    
    // Bandwidth: Only events, not empty polls
    const bytesPerEvent = 200 + avgEventSize; // Headers + payload
    const monthlyEvents = users * avgEventsPerHour * 24 * 30;
    const monthlyBandwidth = (monthlyEvents * bytesPerEvent) / 1e9;
    
    return {
        servers,
        monthlyBandwidth,
        monthlyCost: servers * 500 + monthlyBandwidth * 0.05,
    };
}
 
function estimateWebSocket(
    users: number,
    avgEventsPerHour: number,
    avgEventSize: number
): ResourceEstimate {
    // Memory: 2KB per connection (buffers + state)
    const memoryGB = (users * 2048) / 1e9;
    const serversForMemory = Math.ceil(memoryGB / 28);
    
    // CPU: Ping/pong every 30s + event encoding
    const pingsPerSecond = users / 30;
    const eventsPerSecond = (users * avgEventsPerHour) / 3600;
    const operationsPerSecond = pingsPerSecond + eventsPerSecond;
    const coresNeeded = operationsPerSecond / 50000; // WS more efficient
    const serversForCPU = Math.ceil(coresNeeded / 8);
    
    const servers = Math.max(serversForMemory, serversForCPU);
    
    // Bandwidth: Most efficient (WS frame overhead ~6 bytes)
    const frameOverhead = 6;
    const monthlyEvents = users * avgEventsPerHour * 24 * 30;
    const monthlyPings = (users / 30) * 60 * 60 * 24 * 30 * 2; // ping + pong
    const monthlyBandwidth = (
        (monthlyEvents * (frameOverhead + avgEventSize)) +
        (monthlyPings * 10)
    ) / 1e9;
    
    return {
        servers,
        monthlyBandwidth,
        monthlyCost: servers * 500 + monthlyBandwidth * 0.05,
    };
}
 
// Example: 1M users, 10 events/hour, 200 byte events
console.log('Short Poll (5s):', estimateShortPolling(1_000_000, 5, 200));
// { servers: 25, monthlyBandwidth: 2592, monthlyCost: 12630 }
 
console.log('Long Poll:', estimateLongPolling(1_000_000, 10, 200));
// { servers: 36, monthlyBandwidth: 173, monthlyCost: 18009 }
 
console.log('WebSocket:', estimateWebSocket(1_000_000, 10, 200));
// { servers: 72, monthlyBandwidth: 52, monthlyCost: 36003 }

Memory vs CPU Tradeoff

Persistent connections (Long Poll/SSE/WebSocket) trade CPU for memory. Short polling uses minimal memory but high CPU. At scale, memory is often cheaper than CPU cycles. However, holding 1M connections requires careful resource tuning—file descriptors, TCP buffers, and garbage collection all need configuration.

Infrastructure Compatibility

Not all technologies work equally well across different infrastructure environments. Compatibility with proxies, load balancers, and firewalls varies significantly.

Infrastructure Compatibility Matrix:

Infrastructure Compatibility by Technology
Infrastructure	Short Poll	Long Poll	SSE	WebSocket
Corporate Proxies	✅ Excellent	✅ Good*	⚠️ Variable	❌ Often blocked
CDNs (Cloudflare)	✅ Excellent	✅ Good	✅ Supported	✅ Supported
CDNs (CloudFront)	✅ Excellent	✅ Good	⚠️ Limited	✅ Supported
AWS API Gateway	✅ Excellent	❌ 30s limit	⚠️ Limited	✅ Native support
nginx (default)	✅ Excellent	⚠️ Config needed	⚠️ Config needed	✅ With upgrade
HTTP/2	✅ Excellent	✅ Excellent	✅ Good	N/A (own protocol)
HTTPS	✅ Excellent	✅ Excellent	✅ Excellent	✅ WSS
VPNs	✅ Excellent	✅ Good	✅ Good	⚠️ Variable
Mobile Carriers	✅ Excellent	⚠️ Idle timeout	⚠️ Idle timeout	⚠️ Idle timeout

*Long polling: requires timeout < proxy timeout, typically 30-60 seconds

Why WebSocket Compatibility Varies:

WebSocket requires HTTP upgrade, and many network appliances:

Don't understand WebSocket — Older proxies drop the connection on upgrade
Block non-HTTP protocols — Security policies may prohibit
Inspect/terminate SSL — Man-in-the-middle breaks upgrade
Have connection limits — May not handle many persistent connections

Why Long Polling Is So Compatible:

Long polling uses standard HTTP semantics:

Every request is a normal GET
Every response is normal HTTP with JSON/text body
No special headers required (though some help)
Works through any HTTP-compatible proxy
Falls within infrastructure timeout limits when configured correctly

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
// Production-grade transport selection with fallback
 
class TransportNegotiator {
    private transports = ['websocket', 'sse', 'longpoll'] as const;
    private preferredTransport: typeof this.transports[number] = 'websocket';
    private currentTransport: typeof this.transports[number] | null = null;
    
    /**
     * Probe available transports and select the best one
     */
    async negotiate(): Promise<TransportConnection> {
        // Check cached preference first
        const cached = localStorage.getItem('preferredTransport');
        if (cached && this.transports.includes(cached as any)) {
            try {
                const conn = await this.tryTransport(cached as any);
                return conn;
            } catch {
                // Cached preference no longer works, try others
            }
        }
        
        // Try transports in order of preference
        for (const transport of this.transports) {
            try {
                console.log(`Trying transport: ${transport}`);
                const conn = await this.tryTransport(transport);
                
                // Success - cache this preference
                this.currentTransport = transport;
                localStorage.setItem('preferredTransport', transport);
                
                console.log(`Connected via ${transport}`);
                return conn;
                
            } catch (error) {
                console.warn(`Transport ${transport} failed:`, error);
                continue;
            }
        }
        
        throw new Error('All transports failed');
    }
    
    private async tryTransport(
        type: typeof this.transports[number]
    ): Promise<TransportConnection> {
        const timeout = 10000;
        
        switch (type) {
            case 'websocket':
                return await this.tryWebSocket(timeout);
            case 'sse':
                return await this.trySSE(timeout);
            case 'longpoll':
                return await this.tryLongPoll(timeout);
        }
    }
    
    private async tryWebSocket(timeout: number): Promise<TransportConnection> {
        return new Promise((resolve, reject) => {
            const timer = setTimeout(() => {
                ws.close();
                reject(new Error('WebSocket timeout'));
            }, timeout);
            
            const ws = new WebSocket(`wss://${location.host}/api/ws`);
            
            ws.onopen = () => {
                clearTimeout(timer);
                resolve(new WebSocketTransport(ws));
            };
            
            ws.onerror = (error) => {
                clearTimeout(timer);
                reject(error);
            };
        });
    }
    
    private async trySSE(timeout: number): Promise<TransportConnection> {
        return new Promise((resolve, reject) => {
            const timer = setTimeout(() => {
                es.close();
                reject(new Error('SSE timeout'));
            }, timeout);
            
            const es = new EventSource('/api/events');
            
            es.onopen = () => {
                clearTimeout(timer);
                resolve(new SSETransport(es));
            };
            
            es.onerror = (error) => {
                clearTimeout(timer);
                reject(error);
            };
        });
    }
    
    private async tryLongPoll(timeout: number): Promise<TransportConnection> {
        // Long poll always works - just verify endpoint responds
        const response = await fetch('/api/long-poll/probe', {
            signal: AbortSignal.timeout(timeout),
        });
        
        if (!response.ok) {
            throw new Error(`Long poll probe failed: ${response.status}`);
        }
        
        return new LongPollTransport();
    }
}
 
// This is essentially what Socket.io does internally
const negotiator = new TransportNegotiator();
const connection = await negotiator.negotiate();

The Socket.io Approach

Socket.io made transport fallback famous. It tries WebSocket first, falls back to polling if blocked. This is why many production apps using Socket.io actually run on long polling in corporate environments—the fallback is seamless. Consider whether you need this complexity or can mandate a single transport.

Bidirectional Communication Requirements

A crucial differentiator is whether you need true bidirectional communication or just server-to-client push.

Communication Direction Comparison:

Push Only (Server → Client)

•Notifications
•Feed updates
•Price tickers
•Live scores
•Dashboard metrics
•Alert systems
•Progress updates

Bidirectional (Both Ways)

•Real-time chat
•Collaborative editing
•Multiplayer games
•Interactive trading
•Live auctions
•Cursor sharing
•Voice/video signaling

Technology Suitability:

Requirement	Best Technology	Why
Push only, high compatibility	Long Polling or SSE	Both handle unidirectional push well
Push only, maximum efficiency	SSE	Single connection, minimal overhead
Bidirectional, low latency	WebSocket	Native full-duplex support
Bidirectional, maximum compatibility	Long Poll + REST	Separate channels, universal support

Implementing Bidirectional with Unidirectional Technologies:

Long polling and SSE are inherently unidirectional (server → client). Client-to-server messages require a separate channel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// Long polling: Server → Client
// REST API: Client → Server
 
class BidirectionalLongPollClient {
    private pollClient: LongPollClient;
    
    constructor() {
        this.pollClient = new LongPollClient({
            endpoint: '/api/events/poll',
            onEvent: (events) => this.handleServerEvents(events),
        });
    }
    
    // Receive messages from server via long poll
    private handleServerEvents(events: Event[]): void {
        for (const event of events) {
            switch (event.type) {
                case 'chat_message':
                    this.displayMessage(event.data);
                    break;
                case 'user_joined':
                    this.updateUserList(event.data);
                    break;
                // ... handle other event types
            }
        }
    }
    
    // Send messages to server via REST
    async sendMessage(message: string): Promise<void> {
        const response = await fetch('/api/messages', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ message }),
        });
        
        if (!response.ok) {
            throw new Error('Failed to send message');
        }
        
        // Message will be received back via long poll
        // (provides confirmation and ordering)
    }
    
    async updatePresence(status: 'online' | 'away'): Promise<void> {
        await fetch('/api/presence', {
            method: 'PUT',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ status }),
        });
    }
}
 
// For chat, this pattern works well
// - Sending: ~100-500ms (REST roundtrip)
// - Receiving: ~50-200ms (long poll delivers)
// - Total perceived latency: 150-700ms
 
// For games, this pattern is too slow
// - Game state updates need <50ms
// - WebSocket is mandatory

The Hidden Bidirectional Pattern

Most applications labeled 'requires WebSocket' actually work fine with Long Poll + REST. The latency difference (50ms vs 200ms) is imperceptible for chat. Only latency-critical applications (games, collaborative editors with <100ms sync) truly require WebSocket's bidirectional channel.

Failure Modes and Recovery

Each technology fails differently and requires different recovery strategies. Understanding these patterns is crucial for building reliable systems.

Failure Mode Comparison:

Failure Mode Analysis
Failure Scenario	Short Poll	Long Poll	SSE	WebSocket
Network blip	Miss 1 poll	Reconnect ~100ms	Auto-reconnect	Must reconnect
Server restart	Next poll works	Reconnect immediately	Auto-reconnect	Must reconnect
Client offline 5min	Resume on next poll	Resume with cursor	EventSource resumes	Reconnect + resync
Proxy timeout	Transparent	Handled as timeout	May break stream	Connection killed
Half-open connection	N/A (stateless)	Eventual timeout	Heartbeat detects	Ping/pong detects
Message during reconnect	Delivered on next poll	Cursor ensures delivery	lastEventId resumes	May be lost*

*WebSocket messages can be lost during reconnection unless application-level acknowledgment is implemented.

Recovery Complexity Ranking:

Simplest: Short Polling — Stateless, self-healing. Each poll is independent.
Simple: Long Polling — Cursor-based resumption. Server tracks position.
Moderate: SSE — EventSource auto-reconnects with Last-Event-ID header.
Complex: WebSocket — Application must handle reconnection, state sync, and message acknowledgment.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
// WebSocket requires explicit message acknowledgment for reliability
 
class ReliableWebSocket {
    private ws: WebSocket | null = null;
    private pendingMessages: Map<string, { message: any; timestamp: number }> = new Map();
    private lastAckedSeq = 0;
    private sendSeq = 0;
    
    async connect(): Promise<void> {
        return new Promise((resolve, reject) => {
            this.ws = new WebSocket(`wss://${location.host}/api/ws`);
            
            this.ws.onopen = () => {
                // Request messages since last acknowledged sequence
                this.ws!.send(JSON.stringify({
                    type: 'sync',
                    lastSeq: this.lastAckedSeq,
                }));
                resolve();
            };
            
            this.ws.onmessage = (event) => {
                const msg = JSON.parse(event.data);
                
                if (msg.type === 'ack') {
                    // Server acknowledged our message
                    this.pendingMessages.delete(msg.messageId);
                    return;
                }
                
                if (msg.type === 'sync_response') {
                    // Receive missed messages
                    for (const missed of msg.messages) {
                        this.handleMessage(missed);
                    }
                    return;
                }
                
                // Normal message - acknowledge and process
                this.lastAckedSeq = msg.seq;
                this.ws!.send(JSON.stringify({ type: 'ack', seq: msg.seq }));
                this.handleMessage(msg);
            };
            
            this.ws.onclose = () => this.handleDisconnect();
            this.ws.onerror = () => this.handleDisconnect();
        });
    }
    
    async send(message: any): Promise<void> {
        const messageId = crypto.randomUUID();
        const wrappedMessage = {
            id: messageId,
            seq: ++this.sendSeq,
            payload: message,
        };
        
        // Store for potential retry
        this.pendingMessages.set(messageId, {
            message: wrappedMessage,
            timestamp: Date.now(),
        });
        
        if (this.ws?.readyState === WebSocket.OPEN) {
            this.ws.send(JSON.stringify(wrappedMessage));
        }
        
        // Will be retried on reconnect if not acknowledged
    }
    
    private async handleDisconnect(): Promise<void> {
        // Exponential backoff reconnection
        await sleep(Math.random() * 3000 + 1000);
        
        try {
            await this.connect();
            
            // Resend unacknowledged messages
            for (const [id, { message }] of this.pendingMessages) {
                this.ws!.send(JSON.stringify(message));
            }
        } catch {
            // Retry
            this.handleDisconnect();
        }
    }
    
    private handleMessage(msg: any): void {
        // Application message handling
    }
}
 
// Compare to Long Polling - cursor handles all of this automatically
// No explicit acknowledgment needed - cursor position IS the ack

WebSocket Reliability Is Your Responsibility

WebSocket gives you a raw bidirectional channel with no delivery guarantees. If the connection drops mid-message, the message is lost. If you reconnect after being offline, you've missed all messages. Building reliable WebSocket requires implementing what Long Polling gets for free: sequence numbers, acknowledgments, and gap detection.

Decision Framework

With a deep understanding of each technology, we can now construct a decision framework for selecting the right approach.

Primary Decision Tree:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
START: What is your real-time requirement?
 
                    ┌──────────────────────────────────────────────────────────────┐
                    │                                                              │
                    ▼                                                              │
            ┌───────────────────┐                                                  │
            │ Need bidirectional │                                                 │
            │ communication?     │                                                 │
            └─────────┬─────────┘                                                  │
                      │                                                            │
         ┌────────────┴────────────┐                                               │
         ▼                         ▼                                               │
        YES                        NO                                              │
         │                         │                                               │
         ▼                         ▼                                               │
    ┌─────────────┐         ┌─────────────┐                                        │
    │ Latency     │         │ Maximum     │                                        │
    │ requirement?│         │ compatibility│                                        │
    └──────┬──────┘         │ required?   │                                        │
           │                └──────┬──────┘                                        │
    ┌──────┴──────┐         ┌──────┴──────┐                                        │
    ▼             ▼         ▼             ▼                                        │
  <50ms        >50ms       YES           NO                                        │
    │             │         │             │                                        │
    ▼             ▼         ▼             ▼                                        │
  ┌─────┐     ┌───────┐   ┌───────┐   ┌───────┐                                    │
  │ WS  │     │ Long  │   │ Long  │   │ SSE   │                                    │
  │     │     │ Poll  │   │ Poll  │   │       │                                    │
  │     │     │ + REST│   │       │   │       │                                    │
  └─────┘     └───────┘   └───────┘   └───────┘                                    │
                                               │                                    │
                                               │ Not suitable?                      │
                                               └────────────────────────────────────┘
 
LEGEND:
  WS = WebSocket: Fastest, bidirectional, requires infrastructure support
  SSE = Server-Sent Events: Efficient push, good browser support
  Long Poll = Long Polling: Universal compatibility, simple reliability model
  Long Poll + REST = Long Poll for receive, REST API for send

Scenario-Based Recommendations:

Scenario	Recommended	Reasoning
Enterprise SaaS with corporate clients	Long Polling	Corporate proxies often block WS
Consumer mobile app	WebSocket with Long Poll fallback	Best experience, fallback for edge cases
Simple notifications	Long Polling	Simplest, most reliable
Live dashboard	SSE	Efficient, reconnect handling built-in
Real-time collaboration	WebSocket	Bidirectional, low latency required
Gaming	WebSocket	Latency critical, bidirectional
IoT telemetry	SSE or Long Poll	Push only, often behind restrictive networks
Financial trading	WebSocket	Millisecond latency matters
Chat application	Long Poll + REST or WebSocket	Either works; WS for scale efficiency

When In Doubt, Start Simple

Long Polling is rarely the wrong choice for a first implementation. It works everywhere, is simple to debug, and handles failure gracefully. Start with Long Polling, measure real latency, and upgrade to SSE or WebSocket only if measurements show it's necessary. Premature optimization toward WebSocket often adds complexity without measurable benefit.

Summary: Choosing Wisely

We've conducted a comprehensive comparison of real-time communication technologies. Let's consolidate the key insights:

Key Takeaways

•No technology is universally best — Each excels in different scenarios with different constraints.
•Long Polling trades efficiency for compatibility — Works everywhere, simple reliability model, slight latency cost.
•SSE is ideal for push-only scenarios — Efficient, auto-reconnect, good browser support (except legacy IE).
•WebSocket offers maximum performance — Lowest latency, bidirectional, but requires infrastructure support and careful reliability design.
•Latency differences often don't matter — 50ms vs 200ms is imperceptible for most applications.
•Bidirectional can be simulated — Long Poll + REST handles many 'bidirectional' use cases adequately.
•Fallback strategies provide resilience — Multiple transport support (like Socket.io) ensures connectivity.
•Start simple, upgrade when measured — Long Polling first, optimize based on real metrics.

What's Next:

Now that we understand how long polling compares to alternatives, we'll explore when to specifically choose long polling over other options. The next page provides concrete decision criteria and real-world examples of long polling in action.

Page Complete

You now have a comprehensive understanding of how long polling compares to short polling, SSE, and WebSockets across multiple dimensions. You can articulate the trade-offs and make informed technology selections. Next, we'll explore specific scenarios where long polling is the optimal choice.

4 / 5

Loading learning content...

System Design (HLD)Long Polling

Long Polling: The Art of Simulated Real-Time

LevelIntermediate

Duration55 mins

TopicLong Polling

4 / 5

Comparison with Other Approaches

Choosing the Right Real-Time Technology

What You Will Learn

Technology Overview

Before comparing, let's establish clear definitions of each technology and their fundamental operating models.

The Four Real-Time Approaches:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
1. SHORT POLLING
═════════════════════════════════════════════════════════════════
 
Client                                              Server
   │                                                   │
   │────── Request ──────────────────────────────────▶│
   │                                                   │──┐ Immediate
   │◀───── Response (data or empty) ──────────────────│◀─┘ Response
   │                                                   │
   │  [Wait interval: 1-60 seconds]                    │
   │                                                   │
   │────── Request ──────────────────────────────────▶│
   │◀───── Response ─────────────────────────────────│
   │                                                   │
   ▼                                                   ▼
 
2. LONG POLLING
═════════════════════════════════════════════════════════════════
 
Client                                              Server
   │                                                   │
   │────── Request ──────────────────────────────────▶│
   │                                                   │
   │        [Connection held open 30-60 seconds]       │
   │                                                   │
   │◀───── Response (when data available OR timeout) ─│
   │                                                   │
   │────── Immediate Reconnect ──────────────────────▶│
   │        [Wait for next event...]                   │
   │                                                   │
   ▼                                                   ▼
 
3. SERVER-SENT EVENTS (SSE)
═════════════════════════════════════════════════════════════════
 
Client                                              Server
   │                                                   │
   │────── Request (Accept: text/event-stream) ──────▶│
   │                                                   │
   │◀───── Event 1 ─────────────────────────────────│
   │       (same connection)                           │
   │◀───── Event 2 ─────────────────────────────────│
   │       (same connection)                           │
   │◀───── Event 3 ─────────────────────────────────│
   │       ...                                         │
   │◀───── Event N ─────────────────────────────────│
   │                                                   │
   ▼                     Persistent Connection         ▼
 
4. WEBSOCKETS
═════════════════════════════════════════════════════════════════
 
Client                                              Server
   │                                                   │
   │────── HTTP Upgrade Request ─────────────────────▶│
   │◀───── 101 Switching Protocols ──────────────────│
   │                                                   │
   │◀═══════════════ Full Duplex ═══════════════════▶│
   │                                                   │
   │────── Client Message 1 ─────────────────────────▶│
   │◀───── Server Message 1 ─────────────────────────│
   │◀───── Server Message 2 ─────────────────────────│
   │────── Client Message 2 ─────────────────────────▶│
   │                                                   │
   ▼              Bidirectional Persistent             ▼

Fundamental Characteristics
Characteristic	Short Polling	Long Polling	SSE	WebSocket
Connection Type	New per request	New per event batch	Persistent	Persistent
Direction	Client → Server	Client → Server	Server → Client	Bidirectional
Protocol	HTTP	HTTP	HTTP (streaming)	WS (upgrade from HTTP)
Browser Support	Universal	Universal	All modern (not IE)	All modern
Proxy Compatibility	Excellent	Good	Moderate	Variable

Latency and Performance Comparison

Latency characteristics vary significantly across technologies. The right choice depends on your latency requirements and how you define "real-time."

Theoretical Latency Analysis:

Latency Characteristics (Typical Network Conditions)
Metric	Short Poll (5s)	Long Poll	SSE	WebSocket
Best Case Latency	~50ms (poll hit)	~50ms	~20ms	~10ms
Average Latency	~2.5s (half interval)	~100-200ms	~40ms	~20ms
Worst Case Latency	~5s (full interval)	~500ms	~100ms	~50ms
Connection Setup	~0ms (persistent HTTP)	~0ms	~100ms (initial)	~150ms (upgrade)
Recovery Time	~5s (next poll)	~100ms (reconnect)	~1-3s (auto)	~1-3s (reconnect)

Understanding the Latency Components:

Short Polling Latency:

Events can only be delivered when the poll occurs
Average wait = interval / 2 (e.g., 2.5s for 5s interval)
Decreasing interval reduces latency but increases server load exponentially

Long Polling Latency:

Event delivered as soon as available (~50ms network delay)
Reconnection gap between requests (~50-100ms)
Occasional timeout cycle adds ~0ms (just reconnects)

SSE Latency:

Persistent connection = no reconnection delay
Event buffering in server/proxy may add ~10-50ms
Browser's EventSource API adds minimal overhead

WebSocket Latency:

Lowest possible latency = network round-trip only
No HTTP overhead on established connection
Binary framing more efficient than text-based HTTP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
// Measure end-to-end latency for each technology
 
async function measureLatency() {
    const results = {
        shortPoll: await measureShortPoll(),
        longPoll: await measureLongPoll(),
        sse: await measureSSE(),
        websocket: await measureWebSocket(),
    };
    
    return results;
}
 
async function measureShortPoll(): Promise<LatencyMetrics> {
    const samples: number[] = [];
    
    // Server triggers event at random times
    // Client polls every 2 seconds
    for (let i = 0; i < 100; i++) {
        const eventTime = await triggerServerEvent();
        
        let receivedTime = 0;
        while (true) {
            const response = await fetch('/api/poll');
            const data = await response.json();
            
            if (data.events.find(e => e.timestamp === eventTime)) {
                receivedTime = Date.now();
                break;
            }
            
            await sleep(2000); // Poll interval
        }
        
        samples.push(receivedTime - eventTime);
    }
    
    return computeMetrics(samples);
}
 
async function measureLongPoll(): Promise<LatencyMetrics> {
    const samples: number[] = [];
    
    for (let i = 0; i < 100; i++) {
        const eventTime = await triggerServerEvent();
        
        const response = await fetch('/api/long-poll');
        const receivedTime = Date.now();
        const data = await response.json();
        
        if (data.events.length > 0) {
            samples.push(receivedTime - eventTime);
        }
    }
    
    return computeMetrics(samples);
}
 
async function measureSSE(): Promise<LatencyMetrics> {
    return new Promise((resolve) => {
        const samples: number[] = [];
        let eventTimes: Map<string, number> = new Map();
        
        const es = new EventSource('/api/events');
        
        es.onmessage = (event) => {
            const receivedTime = Date.now();
            const data = JSON.parse(event.data);
            const eventTime = eventTimes.get(data.id);
            
            if (eventTime) {
                samples.push(receivedTime - eventTime);
                eventTimes.delete(data.id);
                
                if (samples.length >= 100) {
                    es.close();
                    resolve(computeMetrics(samples));
                }
            }
        };
        
        // Trigger events
        (async () => {
            for (let i = 0; i < 100; i++) {
                const eventId = await triggerServerEvent();
                eventTimes.set(eventId, Date.now());
                await sleep(100);
            }
        })();
    });
}
 
async function measureWebSocket(): Promise<LatencyMetrics> {
    return new Promise((resolve) => {
        const samples: number[] = [];
        
        const ws = new WebSocket('/api/ws');
        
        ws.onmessage = (event) => {
            const receivedTime = Date.now();
            const data = JSON.parse(event.data);
            samples.push(receivedTime - data.serverTime);
            
            if (samples.length >= 100) {
                ws.close();
                resolve(computeMetrics(samples));
            }
        };
        
        ws.onopen = async () => {
            for (let i = 0; i < 100; i++) {
                await triggerServerEvent();
                await sleep(100);
            }
        };
    });
}

Latency vs Perceived Latency

Resource Consumption Analysis

Different technologies consume server resources differently. Understanding these patterns is critical for capacity planning.

Resource Consumption by Technology:

Resource Consumption Patterns (per 10,000 connected clients)
Resource	Short Poll (5s)	Long Poll	SSE	WebSocket
HTTP Requests/second	2,000	~50*	Initial only	Initial only
TCP Connections	~100 (pooled)	10,000	10,000	10,000
Memory per client	~0 (stateless)	~1KB	~1KB	~2KB
CPU (idle)	High (processing)	Low	Very Low	Very Low
CPU (event burst)	High	Moderate	Low	Very Low
Bandwidth overhead	Very High	Low	Very Low	Lowest

*Long poll requests per second depends on event frequency. With 1 event per client per minute average, only ~170 requests/second (reconnections).

Detailed Resource Analysis:

Short Polling:

High request volume = high CPU for request processing
Each request incurs HTTP parsing, routing, authentication
Stateless = no memory for waiting clients, but...
Database/cache hit on every poll, even when empty
Bandwidth: Full HTTP headers on every request/response

Long Polling:

Request volume = event volume + timeout reconnections
Memory: Must track each waiting request
CPU: Minimal while waiting, spikes during event delivery
Network: Efficient—responses only when data exists

SSE:

Persistent connection = one-time request overhead
Memory: Connection state + event buffer
CPU: Very low—just format events in text/event-stream
Limitation: Unidirectional limits use cases

WebSocket:

Most efficient at steady-state
Higher initial handshake cost
Memory: Per-connection state + frame buffers
CPU: Frame encoding/decoding, ping/pong keep-alive

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
// Calculate server resources needed for 1 million connected users
 
interface ResourceEstimate {
    servers: number;        // 8-core, 32GB servers
    monthlyBandwidth: number; // GB
    monthlyCost: number;    // USD (estimated)
}
 
function estimateShortPolling(
    users: number,
    pollInterval: number,  // seconds
    avgEventSize: number   // bytes
): ResourceEstimate {
    const requestsPerSecond = users / pollInterval;
    const httpOverhead = 500; // bytes per request/response
    const hitRate = 0.01;     // 1% of polls return data
    
    // CPU: ~5000 req/s per core for simple handlers
    const coresNeeded = requestsPerSecond / 5000;
    const servers = Math.ceil(coresNeeded / 8);
    
    // Bandwidth
    const requestsPerMonth = requestsPerSecond * 60 * 60 * 24 * 30;
    const bytesPerRequest = httpOverhead + (avgEventSize * hitRate);
    const monthlyBandwidth = (requestsPerMonth * bytesPerRequest) / 1e9;
    
    return {
        servers,
        monthlyBandwidth,
        monthlyCost: servers * 500 + monthlyBandwidth * 0.05,
    };
}
 
function estimateLongPolling(
    users: number,
    avgEventsPerHour: number,
    avgEventSize: number
): ResourceEstimate {
    // Reconnections: timeout every 30s + after each event
    const timeoutReconnectsPerHour = users * (3600 / 30);
    const eventReconnectsPerHour = users * avgEventsPerHour;
    const totalRequestsPerHour = timeoutReconnectsPerHour + eventReconnectsPerHour;
    
    const requestsPerSecond = totalRequestsPerHour / 3600;
    const coresNeeded = requestsPerSecond / 5000;
    
    // Memory: 1KB per waiting connection
    const memoryGB = (users * 1024) / 1e9;
    const serversForMemory = Math.ceil(memoryGB / 28); // 28GB usable
    const serversForCPU = Math.ceil(coresNeeded / 8);
    const servers = Math.max(serversForMemory, serversForCPU);
    
    // Bandwidth: Only events, not empty polls
    const bytesPerEvent = 200 + avgEventSize; // Headers + payload
    const monthlyEvents = users * avgEventsPerHour * 24 * 30;
    const monthlyBandwidth = (monthlyEvents * bytesPerEvent) / 1e9;
    
    return {
        servers,
        monthlyBandwidth,
        monthlyCost: servers * 500 + monthlyBandwidth * 0.05,
    };
}
 
function estimateWebSocket(
    users: number,
    avgEventsPerHour: number,
    avgEventSize: number
): ResourceEstimate {
    // Memory: 2KB per connection (buffers + state)
    const memoryGB = (users * 2048) / 1e9;
    const serversForMemory = Math.ceil(memoryGB / 28);
    
    // CPU: Ping/pong every 30s + event encoding
    const pingsPerSecond = users / 30;
    const eventsPerSecond = (users * avgEventsPerHour) / 3600;
    const operationsPerSecond = pingsPerSecond + eventsPerSecond;
    const coresNeeded = operationsPerSecond / 50000; // WS more efficient
    const serversForCPU = Math.ceil(coresNeeded / 8);
    
    const servers = Math.max(serversForMemory, serversForCPU);
    
    // Bandwidth: Most efficient (WS frame overhead ~6 bytes)
    const frameOverhead = 6;
    const monthlyEvents = users * avgEventsPerHour * 24 * 30;
    const monthlyPings = (users / 30) * 60 * 60 * 24 * 30 * 2; // ping + pong
    const monthlyBandwidth = (
        (monthlyEvents * (frameOverhead + avgEventSize)) +
        (monthlyPings * 10)
    ) / 1e9;
    
    return {
        servers,
        monthlyBandwidth,
        monthlyCost: servers * 500 + monthlyBandwidth * 0.05,
    };
}
 
// Example: 1M users, 10 events/hour, 200 byte events
console.log('Short Poll (5s):', estimateShortPolling(1_000_000, 5, 200));
// { servers: 25, monthlyBandwidth: 2592, monthlyCost: 12630 }
 
console.log('Long Poll:', estimateLongPolling(1_000_000, 10, 200));
// { servers: 36, monthlyBandwidth: 173, monthlyCost: 18009 }
 
console.log('WebSocket:', estimateWebSocket(1_000_000, 10, 200));
// { servers: 72, monthlyBandwidth: 52, monthlyCost: 36003 }

Memory vs CPU Tradeoff

Infrastructure Compatibility

Not all technologies work equally well across different infrastructure environments. Compatibility with proxies, load balancers, and firewalls varies significantly.

Infrastructure Compatibility Matrix:

Infrastructure Compatibility by Technology
Infrastructure	Short Poll	Long Poll	SSE	WebSocket
Corporate Proxies	✅ Excellent	✅ Good*	⚠️ Variable	❌ Often blocked
CDNs (Cloudflare)	✅ Excellent	✅ Good	✅ Supported	✅ Supported
CDNs (CloudFront)	✅ Excellent	✅ Good	⚠️ Limited	✅ Supported
AWS API Gateway	✅ Excellent	❌ 30s limit	⚠️ Limited	✅ Native support
nginx (default)	✅ Excellent	⚠️ Config needed	⚠️ Config needed	✅ With upgrade
HTTP/2	✅ Excellent	✅ Excellent	✅ Good	N/A (own protocol)
HTTPS	✅ Excellent	✅ Excellent	✅ Excellent	✅ WSS
VPNs	✅ Excellent	✅ Good	✅ Good	⚠️ Variable
Mobile Carriers	✅ Excellent	⚠️ Idle timeout	⚠️ Idle timeout	⚠️ Idle timeout

*Long polling: requires timeout < proxy timeout, typically 30-60 seconds

Why WebSocket Compatibility Varies:

WebSocket requires HTTP upgrade, and many network appliances:

Don't understand WebSocket — Older proxies drop the connection on upgrade
Block non-HTTP protocols — Security policies may prohibit
Inspect/terminate SSL — Man-in-the-middle breaks upgrade
Have connection limits — May not handle many persistent connections

Why Long Polling Is So Compatible:

Long polling uses standard HTTP semantics:

Every request is a normal GET
Every response is normal HTTP with JSON/text body
No special headers required (though some help)
Works through any HTTP-compatible proxy
Falls within infrastructure timeout limits when configured correctly

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
// Production-grade transport selection with fallback
 
class TransportNegotiator {
    private transports = ['websocket', 'sse', 'longpoll'] as const;
    private preferredTransport: typeof this.transports[number] = 'websocket';
    private currentTransport: typeof this.transports[number] | null = null;
    
    /**
     * Probe available transports and select the best one
     */
    async negotiate(): Promise<TransportConnection> {
        // Check cached preference first
        const cached = localStorage.getItem('preferredTransport');
        if (cached && this.transports.includes(cached as any)) {
            try {
                const conn = await this.tryTransport(cached as any);
                return conn;
            } catch {
                // Cached preference no longer works, try others
            }
        }
        
        // Try transports in order of preference
        for (const transport of this.transports) {
            try {
                console.log(`Trying transport: ${transport}`);
                const conn = await this.tryTransport(transport);
                
                // Success - cache this preference
                this.currentTransport = transport;
                localStorage.setItem('preferredTransport', transport);
                
                console.log(`Connected via ${transport}`);
                return conn;
                
            } catch (error) {
                console.warn(`Transport ${transport} failed:`, error);
                continue;
            }
        }
        
        throw new Error('All transports failed');
    }
    
    private async tryTransport(
        type: typeof this.transports[number]
    ): Promise<TransportConnection> {
        const timeout = 10000;
        
        switch (type) {
            case 'websocket':
                return await this.tryWebSocket(timeout);
            case 'sse':
                return await this.trySSE(timeout);
            case 'longpoll':
                return await this.tryLongPoll(timeout);
        }
    }
    
    private async tryWebSocket(timeout: number): Promise<TransportConnection> {
        return new Promise((resolve, reject) => {
            const timer = setTimeout(() => {
                ws.close();
                reject(new Error('WebSocket timeout'));
            }, timeout);
            
            const ws = new WebSocket(`wss://${location.host}/api/ws`);
            
            ws.onopen = () => {
                clearTimeout(timer);
                resolve(new WebSocketTransport(ws));
            };
            
            ws.onerror = (error) => {
                clearTimeout(timer);
                reject(error);
            };
        });
    }
    
    private async trySSE(timeout: number): Promise<TransportConnection> {
        return new Promise((resolve, reject) => {
            const timer = setTimeout(() => {
                es.close();
                reject(new Error('SSE timeout'));
            }, timeout);
            
            const es = new EventSource('/api/events');
            
            es.onopen = () => {
                clearTimeout(timer);
                resolve(new SSETransport(es));
            };
            
            es.onerror = (error) => {
                clearTimeout(timer);
                reject(error);
            };
        });
    }
    
    private async tryLongPoll(timeout: number): Promise<TransportConnection> {
        // Long poll always works - just verify endpoint responds
        const response = await fetch('/api/long-poll/probe', {
            signal: AbortSignal.timeout(timeout),
        });
        
        if (!response.ok) {
            throw new Error(`Long poll probe failed: ${response.status}`);
        }
        
        return new LongPollTransport();
    }
}
 
// This is essentially what Socket.io does internally
const negotiator = new TransportNegotiator();
const connection = await negotiator.negotiate();

The Socket.io Approach

Bidirectional Communication Requirements

A crucial differentiator is whether you need true bidirectional communication or just server-to-client push.

Communication Direction Comparison:

Push Only (Server → Client)

•Notifications
•Feed updates
•Price tickers
•Live scores
•Dashboard metrics
•Alert systems
•Progress updates

Bidirectional (Both Ways)

•Real-time chat
•Collaborative editing
•Multiplayer games
•Interactive trading
•Live auctions
•Cursor sharing
•Voice/video signaling

Technology Suitability:

Requirement	Best Technology	Why
Push only, high compatibility	Long Polling or SSE	Both handle unidirectional push well
Push only, maximum efficiency	SSE	Single connection, minimal overhead
Bidirectional, low latency	WebSocket	Native full-duplex support
Bidirectional, maximum compatibility	Long Poll + REST	Separate channels, universal support

Implementing Bidirectional with Unidirectional Technologies:

Long polling and SSE are inherently unidirectional (server → client). Client-to-server messages require a separate channel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// Long polling: Server → Client
// REST API: Client → Server
 
class BidirectionalLongPollClient {
    private pollClient: LongPollClient;
    
    constructor() {
        this.pollClient = new LongPollClient({
            endpoint: '/api/events/poll',
            onEvent: (events) => this.handleServerEvents(events),
        });
    }
    
    // Receive messages from server via long poll
    private handleServerEvents(events: Event[]): void {
        for (const event of events) {
            switch (event.type) {
                case 'chat_message':
                    this.displayMessage(event.data);
                    break;
                case 'user_joined':
                    this.updateUserList(event.data);
                    break;
                // ... handle other event types
            }
        }
    }
    
    // Send messages to server via REST
    async sendMessage(message: string): Promise<void> {
        const response = await fetch('/api/messages', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ message }),
        });
        
        if (!response.ok) {
            throw new Error('Failed to send message');
        }
        
        // Message will be received back via long poll
        // (provides confirmation and ordering)
    }
    
    async updatePresence(status: 'online' | 'away'): Promise<void> {
        await fetch('/api/presence', {
            method: 'PUT',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ status }),
        });
    }
}
 
// For chat, this pattern works well
// - Sending: ~100-500ms (REST roundtrip)
// - Receiving: ~50-200ms (long poll delivers)
// - Total perceived latency: 150-700ms
 
// For games, this pattern is too slow
// - Game state updates need <50ms
// - WebSocket is mandatory

The Hidden Bidirectional Pattern

Failure Modes and Recovery

Each technology fails differently and requires different recovery strategies. Understanding these patterns is crucial for building reliable systems.

Failure Mode Comparison:

Failure Mode Analysis
Failure Scenario	Short Poll	Long Poll	SSE	WebSocket
Network blip	Miss 1 poll	Reconnect ~100ms	Auto-reconnect	Must reconnect
Server restart	Next poll works	Reconnect immediately	Auto-reconnect	Must reconnect
Client offline 5min	Resume on next poll	Resume with cursor	EventSource resumes	Reconnect + resync
Proxy timeout	Transparent	Handled as timeout	May break stream	Connection killed
Half-open connection	N/A (stateless)	Eventual timeout	Heartbeat detects	Ping/pong detects
Message during reconnect	Delivered on next poll	Cursor ensures delivery	lastEventId resumes	May be lost*

*WebSocket messages can be lost during reconnection unless application-level acknowledgment is implemented.

Recovery Complexity Ranking:

Simplest: Short Polling — Stateless, self-healing. Each poll is independent.
Simple: Long Polling — Cursor-based resumption. Server tracks position.
Moderate: SSE — EventSource auto-reconnects with Last-Event-ID header.
Complex: WebSocket — Application must handle reconnection, state sync, and message acknowledgment.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
// WebSocket requires explicit message acknowledgment for reliability
 
class ReliableWebSocket {
    private ws: WebSocket | null = null;
    private pendingMessages: Map<string, { message: any; timestamp: number }> = new Map();
    private lastAckedSeq = 0;
    private sendSeq = 0;
    
    async connect(): Promise<void> {
        return new Promise((resolve, reject) => {
            this.ws = new WebSocket(`wss://${location.host}/api/ws`);
            
            this.ws.onopen = () => {
                // Request messages since last acknowledged sequence
                this.ws!.send(JSON.stringify({
                    type: 'sync',
                    lastSeq: this.lastAckedSeq,
                }));
                resolve();
            };
            
            this.ws.onmessage = (event) => {
                const msg = JSON.parse(event.data);
                
                if (msg.type === 'ack') {
                    // Server acknowledged our message
                    this.pendingMessages.delete(msg.messageId);
                    return;
                }
                
                if (msg.type === 'sync_response') {
                    // Receive missed messages
                    for (const missed of msg.messages) {
                        this.handleMessage(missed);
                    }
                    return;
                }
                
                // Normal message - acknowledge and process
                this.lastAckedSeq = msg.seq;
                this.ws!.send(JSON.stringify({ type: 'ack', seq: msg.seq }));
                this.handleMessage(msg);
            };
            
            this.ws.onclose = () => this.handleDisconnect();
            this.ws.onerror = () => this.handleDisconnect();
        });
    }
    
    async send(message: any): Promise<void> {
        const messageId = crypto.randomUUID();
        const wrappedMessage = {
            id: messageId,
            seq: ++this.sendSeq,
            payload: message,
        };
        
        // Store for potential retry
        this.pendingMessages.set(messageId, {
            message: wrappedMessage,
            timestamp: Date.now(),
        });
        
        if (this.ws?.readyState === WebSocket.OPEN) {
            this.ws.send(JSON.stringify(wrappedMessage));
        }
        
        // Will be retried on reconnect if not acknowledged
    }
    
    private async handleDisconnect(): Promise<void> {
        // Exponential backoff reconnection
        await sleep(Math.random() * 3000 + 1000);
        
        try {
            await this.connect();
            
            // Resend unacknowledged messages
            for (const [id, { message }] of this.pendingMessages) {
                this.ws!.send(JSON.stringify(message));
            }
        } catch {
            // Retry
            this.handleDisconnect();
        }
    }
    
    private handleMessage(msg: any): void {
        // Application message handling
    }
}
 
// Compare to Long Polling - cursor handles all of this automatically
// No explicit acknowledgment needed - cursor position IS the ack

WebSocket Reliability Is Your Responsibility

Decision Framework

With a deep understanding of each technology, we can now construct a decision framework for selecting the right approach.

Primary Decision Tree:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
START: What is your real-time requirement?
 
                    ┌──────────────────────────────────────────────────────────────┐
                    │                                                              │
                    ▼                                                              │
            ┌───────────────────┐                                                  │
            │ Need bidirectional │                                                 │
            │ communication?     │                                                 │
            └─────────┬─────────┘                                                  │
                      │                                                            │
         ┌────────────┴────────────┐                                               │
         ▼                         ▼                                               │
        YES                        NO                                              │
         │                         │                                               │
         ▼                         ▼                                               │
    ┌─────────────┐         ┌─────────────┐                                        │
    │ Latency     │         │ Maximum     │                                        │
    │ requirement?│         │ compatibility│                                        │
    └──────┬──────┘         │ required?   │                                        │
           │                └──────┬──────┘                                        │
    ┌──────┴──────┐         ┌──────┴──────┐                                        │
    ▼             ▼         ▼             ▼                                        │
  <50ms        >50ms       YES           NO                                        │
    │             │         │             │                                        │
    ▼             ▼         ▼             ▼                                        │
  ┌─────┐     ┌───────┐   ┌───────┐   ┌───────┐                                    │
  │ WS  │     │ Long  │   │ Long  │   │ SSE   │                                    │
  │     │     │ Poll  │   │ Poll  │   │       │                                    │
  │     │     │ + REST│   │       │   │       │                                    │
  └─────┘     └───────┘   └───────┘   └───────┘                                    │
                                               │                                    │
                                               │ Not suitable?                      │
                                               └────────────────────────────────────┘
 
LEGEND:
  WS = WebSocket: Fastest, bidirectional, requires infrastructure support
  SSE = Server-Sent Events: Efficient push, good browser support
  Long Poll = Long Polling: Universal compatibility, simple reliability model
  Long Poll + REST = Long Poll for receive, REST API for send

Scenario-Based Recommendations:

Scenario	Recommended	Reasoning
Enterprise SaaS with corporate clients	Long Polling	Corporate proxies often block WS
Consumer mobile app	WebSocket with Long Poll fallback	Best experience, fallback for edge cases
Simple notifications	Long Polling	Simplest, most reliable
Live dashboard	SSE	Efficient, reconnect handling built-in
Real-time collaboration	WebSocket	Bidirectional, low latency required
Gaming	WebSocket	Latency critical, bidirectional
IoT telemetry	SSE or Long Poll	Push only, often behind restrictive networks
Financial trading	WebSocket	Millisecond latency matters
Chat application	Long Poll + REST or WebSocket	Either works; WS for scale efficiency

When In Doubt, Start Simple

Summary: Choosing Wisely

We've conducted a comprehensive comparison of real-time communication technologies. Let's consolidate the key insights:

Key Takeaways

•No technology is universally best — Each excels in different scenarios with different constraints.
•Long Polling trades efficiency for compatibility — Works everywhere, simple reliability model, slight latency cost.
•SSE is ideal for push-only scenarios — Efficient, auto-reconnect, good browser support (except legacy IE).
•WebSocket offers maximum performance — Lowest latency, bidirectional, but requires infrastructure support and careful reliability design.
•Latency differences often don't matter — 50ms vs 200ms is imperceptible for most applications.
•Bidirectional can be simulated — Long Poll + REST handles many 'bidirectional' use cases adequately.
•Fallback strategies provide resilience — Multiple transport support (like Socket.io) ensures connectivity.
•Start simple, upgrade when measured — Long Polling first, optimize based on real metrics.

What's Next:

Page Complete

4 / 5