System Design (HLD)WebSockets

WebSockets: Real-Time Bidirectional Communication

LevelIntermediate

Duration75 mins

TopicWebSockets

4 / 5

WebSocket vs HTTP

Choosing the Right Protocol for Real-Time Features

WebSockets aren't always the answer. Despite their power for real-time communication, they introduce complexity that isn't justified for every use case. HTTP—in its various forms—remains the workhorse of web communication, and modern techniques have extended its capabilities remarkably.

The decision between WebSocket and HTTP isn't binary. It's a spectrum of trade-offs involving latency requirements, message frequency, bidirectionality needs, infrastructure compatibility, and operational complexity. A skilled engineer chooses the simplest approach that meets requirements.

This page provides a rigorous, head-to-head comparison. You'll learn not just the technical differences, but the decision framework that guides protocol selection in real-world systems.

What You Will Learn

By the end of this page, you will understand the fundamental architectural differences between WebSocket and HTTP; compare their performance characteristics for various workloads; analyze HTTP-based alternatives (polling, long-polling, SSE); recognize when WebSocket complexity is justified; and apply a decision framework for protocol selection.

Fundamental Architecture Comparison

Before comparing specific features, we need to understand the fundamental architectural differences between HTTP and WebSocket. These protocols were designed for different purposes and make different trade-offs.

Architectural Foundation Comparison
Characteristic	HTTP	WebSocket
Communication Model	Request-Response	Bidirectional messaging
Connection Lifecycle	Per-request (or keep-alive pool)	Persistent for session duration
Who Initiates	Client only	Either party, any time
Protocol Layer	Application (L7) via TCP	Application (L7) via TCP
Message Framing	Headers + body per message	Lightweight frame headers
State Management	Stateless (application manages state)	Stateful (connection maintains state)
URL Semantics	Resource-oriented (GET /users/123)	Endpoint-oriented (connect once)

Protocol Comparison Visualization
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
// ═══════════════════════════════════════════════════════════════
// HTTP COMMUNICATION PATTERN
// ═══════════════════════════════════════════════════════════════
 
CLIENT                                    SERVER
   │                                         │
   │◄─────── Connection Established ─────────│
   │                                         │
   │ GET /api/messages HTTP/1.1             │
   │ Headers: ~500 bytes                    │
   │──────────────────────────────────────►│|
   │                                         │ Process
   │        HTTP/1.1 200 OK                 │
   │        Headers: ~400 bytes             │
   │◄──────────────────────────────────────│|
   │                                         │
   │ GET /api/messages HTTP/1.1 (repeat)    │
   │──────────────────────────────────────►│|  Every request
   │                                         │   carries full
   │◄──────────────────────────────────────│|   headers
   │                                         │
 
// Each exchange is independent
// Server cannot send until client asks
// ~1KB overhead per round-trip
 
 
// ═══════════════════════════════════════════════════════════════
// WEBSOCKET COMMUNICATION PATTERN
// ═══════════════════════════════════════════════════════════════
 
CLIENT                                    SERVER
   │                                         │
   │◄─────── HTTP Upgrade Handshake ─────────│ (~1KB, once)
   │                                         │
   │═══════════ WebSocket Open ══════════════│
   │                                         │
   │ Frame: 2-10 bytes + payload            │
   │──────────────────────────────────────►│|  Message A
   │                                         │
   │ Frame: 2-10 bytes + payload            │  
   │◄──────────────────────────────────────│|  Server pushes
   │                                         │
   │ Frame: 2-10 bytes + payload            │
   │◄──────────────────────────────────────│|  Server pushes again
   │                                         │   (no request needed)
   │ Frame: 2-10 bytes + payload            │
   │──────────────────────────────────────►│|  Client responds
   │                                         │
   │═══════════ Connection Persists ═════════│
 
// Single handshake, then minimal per-message overhead
// Either party sends whenever they want
// ~10 bytes overhead per message

The key insight:

HTTP optimizes for discrete transactions—independent requests that don't need to remember previous exchanges. Each request is self-contained, making scaling straightforward.

WebSocket optimizes for ongoing conversations—continuous dialogue where both parties contribute and context is maintained. The connection IS the session.

Performance Deep Dive

Performance comparisons between WebSocket and HTTP depend heavily on the workload. Let's analyze the key performance dimensions:

Latency Analysis:

For a single message, the latency breakdown differs significantly:

HTTP Request (cold connection):

DNS lookup: 20-100ms (cached after first)
TCP handshake: 1 RTT (~30ms cross-continent)
TLS handshake: 2 RTT (~60ms with TLS 1.3 0-RTT possible)
HTTP request/response: 1 RTT (~30ms)
Total: ~140ms minimum for first request

HTTP Request (keep-alive):

HTTP request/response: 1 RTT (~30ms)
Total: ~30ms per request

WebSocket Message (after connection):

Frame transmission: < 1ms on fast networks
Total: ~1-5ms end-to-end

WebSocket's latency advantage comes from eliminating per-message handshaking. For applications with frequent messages, this compounds dramatically.

Latency Comparison by Workload
Scenario	HTTP Latency	WebSocket Latency	Winner
Single API call	30-50ms	N/A (overkill)	HTTP
10 messages / minute	30-50ms each	1-5ms each	Marginal WebSocket
1 message / second	30-50ms each	1-5ms each	WebSocket
10 messages / second	30-50ms each (pooled)	1-5ms each	Clear WebSocket
Real-time streaming	Long-poll: ~100ms gaps	< 10ms	Strong WebSocket

Bandwidth Analysis:

HTTP headers dominate overhead for small messages:

Typical HTTP Request:

GET /api/status HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0...
Accept: application/json
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: session=abc123...
Authorization: Bearer eyJhbGc...

Size: 500-2000 bytes

WebSocket Frame:

[2-byte header] + [4-byte mask] + [payload]

Size: 6-14 bytes overhead

For a 100-byte payload:

HTTP: 600-2100 bytes (6-21x overhead)
WebSocket: 106-114 bytes (6-14% overhead)

Bandwidth Calculation Example
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
// Scenario: Real-time dashboard updating every second for 1000 users
// Each update: 200 bytes of data
 
// ═══════════════════════════════════════════════════════════════
// HTTP POLLING
// ═══════════════════════════════════════════════════════════════
 
const httpOverheadPerRequest = 800;  // Conservative estimate
const payloadSize = 200;
const usersCount = 1000;
const updatesPerMinute = 60;
 
const httpBytesPerUser = (httpOverheadPerRequest + payloadSize) * updatesPerMinute;
// = 1000 * 60 = 60,000 bytes/user/minute
 
const httpTotalPerMinute = httpBytesPerUser * usersCount;
// = 60,000 * 1000 = 60,000,000 bytes/minute = ~60 MB/minute
 
// Plus: client sends request headers too
const httpClientOverhead = 600 * updatesPerMinute * usersCount;
// = 600 * 60 * 1000 = 36,000,000 bytes/minute = ~36 MB/minute
 
// Total HTTP: ~96 MB/minute = ~1.6 MB/second
 
 
// ═══════════════════════════════════════════════════════════════
// WEBSOCKET PUSH
// ═══════════════════════════════════════════════════════════════
 
const wsOverheadPerMessage = 8;  // Frame header + mask
const payloadSize = 200;
const usersCount = 1000;
const updatesPerMinute = 60;
 
const wsBytesPerUser = (wsOverheadPerMessage + payloadSize) * updatesPerMinute;
// = 208 * 60 = 12,480 bytes/user/minute
 
const wsTotalPerMinute = wsBytesPerUser * usersCount;
// = 12,480 * 1000 = 12,480,000 bytes/minute = ~12.5 MB/minute
 
// Total WebSocket: ~12.5 MB/minute = ~0.2 MB/second
 
 
// COMPARISON
// HTTP: 96 MB/minute
// WebSocket: 12.5 MB/minute
// WebSocket uses 87% less bandwidth

HTTP/2 Reduces the Gap

HTTP/2 header compression (HPACK) significantly reduces repeated header overhead. Multiple requests multiplex over one connection. This narrows the bandwidth gap, though WebSocket frames remain more efficient for high-frequency small messages.

HTTP Alternatives for Real-Time

Before committing to WebSocket complexity, consider HTTP-based techniques that provide varying degrees of real-time capability. These approaches work with existing infrastructure and may suffice for many use cases.

Short Polling:

The simplest approach—client requests updates at regular intervals:

setInterval(async () => {
  const response = await fetch('/api/updates');
  const data = await response.json();
  if (data.hasUpdates) {
    handleUpdates(data.updates);
  }
}, 5000); // Every 5 seconds

Pros: Simple, works everywhere, easy debugging, stateless Cons: Latency up to polling interval, wasted requests when no updates, server load scales with users × frequency

Best for: Low-frequency updates (dashboards refreshing every minute), situations where near-real-time isn't required

Long Polling:

Client sends request, server holds it until data is available:

async function longPoll() {
  try {
    const response = await fetch('/api/updates?timeout=30');
    const data = await response.json();
    handleUpdates(data.updates);
  } catch (error) {
    await sleep(1000); // Brief pause before retry
  }
  longPoll(); // Immediately reconnect
}
longPoll();

Pros: Near-instant updates, works through all proxies, no special protocol Cons: Server holds connections (resource usage), HTTP overhead per update, unidirectional

Best for: Moderate real-time needs where WebSocket isn't supported or is overkill

Server-Sent Events (SSE):

Dedicated HTTP streaming from server to client:

// Client
const evtSource = new EventSource('/api/stream');
evtSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  handleUpdate(data);
};

// Server (Node.js)
app.get('/api/stream', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  
  const sendEvent = (data) => {
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  };
  
  // Subscribe to updates
  eventBus.on('update', sendEvent);
  req.on('close', () => eventBus.off('update', sendEvent));
});

Pros: Simple API, automatic reconnection, event IDs for resumption, works with HTTP/2 Cons: Server-to-client only, limited browser connections (~6 per domain), text-only (base64 for binary)

Best for: Live feeds, notifications, dashboards—anywhere server pushes but client doesn't need to push back

HTTP Real-Time Technique Comparison
Technique	Direction	Latency	Complexity	Best Use Case
Short Polling	Client → Server	Up to interval	Very Low	Infrequent updates OK
Long Polling	Server → Client	~Instant	Low	Moderate real-time, legacy support
SSE	Server → Client	~Instant	Low	Live feeds, notifications
WebSocket	Bidirectional	~Instant	Medium-High	Chat, gaming, collaboration

SSE is Often Enough

Many "real-time" features are actually one-way: notifications, live updates, activity feeds. SSE handles these elegantly with less complexity than WebSocket. Reserve WebSocket for truly bidirectional needs—chat, gaming, collaborative editing where both parties initiate frequently.

Infrastructure Compatibility

HTTP's universal support is a major practical advantage. WebSocket, while widely supported, introduces compatibility challenges that should factor into your decision.

Infrastructure Considerations

•Proxies: Some corporate proxies, especially older ones, don't properly forward WebSocket upgrades. They may hold connections, timeout unexpectedly, or block entirely. HTTP works through everything.
•Load Balancers: Layer 4 (TCP) load balancers work with WebSocket. Layer 7 (HTTP) load balancers need explicit WebSocket support. Session affinity configuration required.
•CDNs: Most CDNs don't proxy WebSocket (they're designed for cacheable content). You'll need separate infrastructure or CDN WebSocket add-ons.
•API Gateways: Support varies. AWS API Gateway supports WebSocket. Others may not, or may impose limitations.
•Serverless: WebSocket on serverless is complex. AWS API Gateway + Lambda works but has quirks. Many serverless platforms don't support WebSocket.
•Monitoring: HTTP requests are easily logged and monitored. WebSocket connections require different tooling for traffic analysis.

Platform Support Matrix
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
// ═══════════════════════════════════════════════════════════════
// WEBSOCKET SUPPORT BY PLATFORM
// ═══════════════════════════════════════════════════════════════
 
LOAD BALANCERS
├─ AWS ALB:           ✅ Full support (connection stickiness available)
├─ AWS NLB:           ✅ Full support (TCP level)
├─ GCP Load Balancer: ✅ Full support
├─ Azure LB:          ✅ Full support
├─ NGINX:             ✅ Full support (requires configuration)
├─ HAProxy:           ✅ Full support
└─ Classic ELB:       ⚠️ Limited (use TCP mode, not HTTP)
 
API GATEWAYS
├─ AWS API Gateway:   ✅ WebSocket APIs supported
├─ Kong:              ✅ Full support with plugins
├─ Azure API Mgmt:    ✅ Full support
├─ Apigee:            ⚠️ Limited support
└─ Generic reverse proxy: ⚠️ Configuration required
 
SERVERLESS
├─ AWS Lambda:        ⚠️ Via API Gateway only, connection mgmt separate
├─ Azure Functions:   ⚠️ Via SignalR service
├─ GCP Cloud Run:     ✅ Full support (with caveats)
├─ Cloudflare Workers:✅ Durable Objects for state
└─ Vercel:            ❌ Not supported (use third-party)
 
CDNS
├─ Cloudflare:        ✅ WebSocket proxying supported
├─ Fastly:            ✅ Supported
├─ AWS CloudFront:    ⚠️ Limited (origin only, not edge)
└─ Akamai:            ✅ Supported with configuration
 
BROWSERS
├─ Chrome:            ✅ Since v4
├─ Firefox:           ✅ Since v11
├─ Safari:            ✅ Since v6
├─ Edge:              ✅ Since v12
├─ IE:                ⚠️ IE10+ only
└─ Mobile browsers:   ✅ Generally good support

Corporate Network Challenges

Enterprise environments often have aggressive proxies that terminate long-lived connections, deep packet inspection that interferes with WebSocket frames, or outright blocks on non-HTTP traffic. If your users are behind corporate firewalls, test WebSocket thoroughly and implement fallback to long-polling.

Operational Complexity

HTTP's statelessness makes it operationally simple. WebSocket's statefulness introduces complexity across the entire operations lifecycle:

HTTP Operations

•Deploy updates: Stop process, start new one. In-flight requests may fail, clients retry automatically.
•Scale up: Add servers to load balancer pool. Traffic distributes immediately.
•Scale down: Remove server, let connections drain naturally. Simple.
•Debug: Standard HTTP logging. Request/response pairs. Easy to trace.
•Monitor: Request counts, latency percentiles, error rates. Well-established patterns.

WebSocket Operations

•Deploy updates: Must drain connections gracefully. Clients reconnect (connection storm). State may be lost.
•Scale up: New server joins pool but existing connections stay put. Uneven distribution.
•Scale down: Must migrate connections or force reconnect. Coordinated drain needed.
•Debug: Bidirectional message streams. Harder to trace. Stateful context needed.
•Monitor: Connection counts, message rates, connection durations. Different tooling required.

Deployment challenges:

Rolling deployments with WebSocket require careful orchestration:

Graceful shutdown signal — New server version starts receiving new connections
Drain period — Old server stops accepting new connections, keeps existing
Force disconnect — After drain timeout, close remaining connections with appropriate code (1012 Service Restart)
Reconnection storm — All disconnected clients reconnect simultaneously
State recovery — Clients must re-establish subscriptions, catch up on missed messages

This complexity is manageable but requires planning that HTTP deployments don't need.

Graceful Shutdown Implementation
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
// Graceful WebSocket server shutdown for deployments
 
class WebSocketServer {
    private connections = new Set<WebSocket>();
    private isShuttingDown = false;
    
    handleConnection(ws: WebSocket) {
        if (this.isShuttingDown) {
            // Reject new connections during shutdown
            ws.close(1013, 'Try again later');
            return;
        }
        
        this.connections.add(ws);
        ws.on('close', () => this.connections.delete(ws));
    }
    
    async gracefulShutdown(drainTimeoutMs: number = 30000) {
        console.log('Starting graceful shutdown...');
        this.isShuttingDown = true;
        
        // Notify clients to prepare for reconnection
        for (const ws of this.connections) {
            if (ws.readyState === WebSocket.OPEN) {
                ws.send(JSON.stringify({ 
                    type: 'server_shutdown', 
                    reconnectAfterMs: 5000 
                }));
            }
        }
        
        // Wait for drain period
        const drainStart = Date.now();
        while (this.connections.size > 0) {
            if (Date.now() - drainStart > drainTimeoutMs) {
                console.log(`Force closing ${this.connections.size} connections`);
                break;
            }
            await sleep(1000);
            console.log(`Waiting for ${this.connections.size} connections to close...`);
        }
        
        // Force close remaining connections
        for (const ws of this.connections) {
            ws.close(1012, 'Service restart');
        }
        
        console.log('Shutdown complete');
    }
}
 
// Usage: Listen for SIGTERM from orchestrator
process.on('SIGTERM', async () => {
    await server.gracefulShutdown(30000);
    process.exit(0);
});

Decision Framework

With a thorough understanding of the trade-offs, we can establish a decision framework for choosing between WebSocket and HTTP-based approaches.

Start with HTTP, graduate to WebSocket:

The guiding principle is to use the simplest solution that meets requirements. WebSocket should be a deliberate choice, not a default.

Use regular HTTP when:

Updates are infrequent (< 1/minute)
Latency of seconds is acceptable
Request-response fits naturally
You want maximum infrastructure compatibility
Serverless is your deployment model

Use SSE when:

Server needs to push to client frequently
Client-to-server is infrequent (can use separate HTTP requests)
You want simpler implementation than WebSocket
Built-in reconnection is valuable

Use WebSocket when:

Both parties send messages frequently
Sub-second latency is required
Binary data efficiency matters
State must be maintained across messages
Real-time bidirectional is core to the feature

Decision Flowchart
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
// PROTOCOL SELECTION DECISION TREE
 
                        START
                          │
                          ▼
            ┌──────────────────────────────┐
            │ Does the server need to      │
            │ push updates to the client?  │
            └─────────────┬────────────────┘
                          │
              no ─────────┼───────── yes
              │           │           │
              ▼           │           ▼
          HTTP REST       │   ┌───────────────────────────┐
          (polling if     │   │ Does the client also      │
           needed)        │   │ send frequent messages?   │
                          │   └───────────┬───────────────┘
                          │               │
                          │   no ─────────┼───────── yes
                          │   │           │           │
                          │   ▼           │           ▼
                          │  SSE          │   ┌───────────────────────────┐
                          │  (or long     │   │ Is sub-second latency    │
                          │   polling)    │   │ required?                │
                          │               │   └───────────┬───────────────┘
                          │               │               │
                          │               │   no ─────────┼───────── yes
                          │               │   │           │           │
                          │               │   ▼           │           ▼
                          │               │  HTTP/2 with  │       WebSocket
                          │               │  bidirectional│
                          │               │  streaming    │
                          │               │  (or consider │
                          │               │   WebSocket)  │
 
 
// COMMON USE CASE MAPPINGS
 
Chat application:           → WebSocket (bidirectional, real-time)
Live notifications:         → SSE or WebSocket (server push)
Real-time dashboard:        → SSE (server push, infrequent client input)
Collaborative editing:      → WebSocket (bidirectional, state sync)
Live sports scores:         → SSE (server push)
Online gaming:              → WebSocket (bidirectional, low latency)
Stock ticker:               → SSE or WebSocket (depends on trade capability)
IoT device control:         → WebSocket (bidirectional commands)
Comment section updates:    → Polling or SSE (low frequency)
Presence indicators:        → WebSocket (bidirectional heartbeats)

The Hybrid Approach

Many production systems use both protocols. Use HTTP for standard API calls, transactional operations, and infrequent updates. Use WebSocket for the specific features that need real-time. Socket.io and similar libraries implement this pattern with automatic fallback.

Case Studies: Protocol Choices in Practice

Let's examine how real systems make protocol choices, illustrating the decision framework in practice.

Case Study 1: Twitter/X Timeline

Requirements: Tweets appear in timeline in near-real-time; users compose tweets (infrequent client-to-server).

Decision: Uses HTTP polling with variable intervals. New tweets fetched every 15-60 seconds depending on activity. Notifications use push notifications (mobile) or polling (web).

Why not WebSocket? The latency requirement isn't strict (second delay is acceptable). The scale (hundreds of millions of users) would make WebSocket infrastructure prohibitively complex. Most users don't compose frequently.

Lesson: Even real-time-feeling features may not need WebSocket when near-real-time suffices.

Case Study 2: Figma Collaborative Design

Requirements: Multiple users edit simultaneously; cursor positions visible in real-time; changes appear instantly.

Decision: WebSocket for all interactive operations. Every cursor move, selection change, and edit transmits immediately.

Why WebSocket? True collaboration requires sub-second latency. Users expect to see others' cursors moving smoothly. High-frequency bidirectional data (every cursor move generates an event).

Lesson: When real-time collaboration is the core product, WebSocket complexity is justified.

Case Study 3: GitHub Actions Build Logs

Requirements: Stream build output as it happens; user watches build complete.

Decision: Server-Sent Events. Log lines stream from server as they're produced.

Why SSE over WebSocket? Log streaming is unidirectional (server → client). SSE's built-in reconnection handles network blips gracefully. Simpler implementation for a feature that's not core to GitHub's product.

Lesson: SSE is often the right choice for server-push-only features.

Protocol Usage by Company/Feature
Company	Feature	Protocol	Rationale
Slack	Messages	WebSocket	Real-time chat, bidirectional
Slack	API calls	HTTP	Standard request-response
Stripe	Webhooks	HTTP callbacks	Event delivery, async
Discord	Voice/Video	WebSocket + WebRTC	Real-time streaming
Notion	Collaboration	WebSocket	Real-time sync
Netflix	Playback position	HTTP	Infrequent sync
Trading platforms	Order book	WebSocket	Sub-ms latency required

Summary: Choosing the Right Tool

The choice between WebSocket and HTTP is a trade-off, not a competition. Each protocol excels in different scenarios. Let's consolidate the key insights:

Key Takeaways

•HTTP optimizes for transactions, WebSocket for conversations — Choose based on your communication pattern, not hype.
•WebSocket excels at low-latency, high-frequency, bidirectional messaging — Chat, gaming, collaborative editing are natural fits.
•SSE is often overlooked but powerful — For server-push without client-push, SSE is simpler than WebSocket with similar performance.
•HTTP/2 narrows the efficiency gap — Header compression and multiplexing reduce HTTP overhead significantly.
•Infrastructure compatibility favors HTTP — Proxies, CDNs, serverless, and monitoring tools work better with HTTP.
•Operational complexity is real — WebSocket's statefulness complicates deployments, scaling, and debugging.
•Start simple, graduate when needed — Default to HTTP; use WebSocket when requirements demand it.
•Hybrid approaches are common — Use HTTP for standard APIs, WebSocket for real-time features.

What's next:

We've compared WebSocket to HTTP and established when each is appropriate. The final page of this module examines WebSocket use cases—a comprehensive survey of applications where WebSocket shines, with implementation considerations for each.

Page Complete

You now have a comprehensive understanding of WebSocket vs HTTP trade-offs. You can analyze workload requirements, evaluate HTTP alternatives like SSE, assess infrastructure compatibility, and apply a decision framework to choose the right protocol for real-time features.

4 / 5

Loading learning content...

System Design (HLD)WebSockets

WebSockets: Real-Time Bidirectional Communication

LevelIntermediate

Duration75 mins

TopicWebSockets

4 / 5

WebSocket vs HTTP

Choosing the Right Protocol for Real-Time Features

This page provides a rigorous, head-to-head comparison. You'll learn not just the technical differences, but the decision framework that guides protocol selection in real-world systems.

What You Will Learn

Fundamental Architecture Comparison

Architectural Foundation Comparison
Characteristic	HTTP	WebSocket
Communication Model	Request-Response	Bidirectional messaging
Connection Lifecycle	Per-request (or keep-alive pool)	Persistent for session duration
Who Initiates	Client only	Either party, any time
Protocol Layer	Application (L7) via TCP	Application (L7) via TCP
Message Framing	Headers + body per message	Lightweight frame headers
State Management	Stateless (application manages state)	Stateful (connection maintains state)
URL Semantics	Resource-oriented (GET /users/123)	Endpoint-oriented (connect once)

Protocol Comparison Visualization
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
// ═══════════════════════════════════════════════════════════════
// HTTP COMMUNICATION PATTERN
// ═══════════════════════════════════════════════════════════════
 
CLIENT                                    SERVER
   │                                         │
   │◄─────── Connection Established ─────────│
   │                                         │
   │ GET /api/messages HTTP/1.1             │
   │ Headers: ~500 bytes                    │
   │──────────────────────────────────────►│|
   │                                         │ Process
   │        HTTP/1.1 200 OK                 │
   │        Headers: ~400 bytes             │
   │◄──────────────────────────────────────│|
   │                                         │
   │ GET /api/messages HTTP/1.1 (repeat)    │
   │──────────────────────────────────────►│|  Every request
   │                                         │   carries full
   │◄──────────────────────────────────────│|   headers
   │                                         │
 
// Each exchange is independent
// Server cannot send until client asks
// ~1KB overhead per round-trip
 
 
// ═══════════════════════════════════════════════════════════════
// WEBSOCKET COMMUNICATION PATTERN
// ═══════════════════════════════════════════════════════════════
 
CLIENT                                    SERVER
   │                                         │
   │◄─────── HTTP Upgrade Handshake ─────────│ (~1KB, once)
   │                                         │
   │═══════════ WebSocket Open ══════════════│
   │                                         │
   │ Frame: 2-10 bytes + payload            │
   │──────────────────────────────────────►│|  Message A
   │                                         │
   │ Frame: 2-10 bytes + payload            │  
   │◄──────────────────────────────────────│|  Server pushes
   │                                         │
   │ Frame: 2-10 bytes + payload            │
   │◄──────────────────────────────────────│|  Server pushes again
   │                                         │   (no request needed)
   │ Frame: 2-10 bytes + payload            │
   │──────────────────────────────────────►│|  Client responds
   │                                         │
   │═══════════ Connection Persists ═════════│
 
// Single handshake, then minimal per-message overhead
// Either party sends whenever they want
// ~10 bytes overhead per message

The key insight:

HTTP optimizes for discrete transactions—independent requests that don't need to remember previous exchanges. Each request is self-contained, making scaling straightforward.

WebSocket optimizes for ongoing conversations—continuous dialogue where both parties contribute and context is maintained. The connection IS the session.

Performance Deep Dive

Performance comparisons between WebSocket and HTTP depend heavily on the workload. Let's analyze the key performance dimensions:

Latency Analysis:

For a single message, the latency breakdown differs significantly:

HTTP Request (cold connection):

DNS lookup: 20-100ms (cached after first)
TCP handshake: 1 RTT (~30ms cross-continent)
TLS handshake: 2 RTT (~60ms with TLS 1.3 0-RTT possible)
HTTP request/response: 1 RTT (~30ms)
Total: ~140ms minimum for first request

HTTP Request (keep-alive):

HTTP request/response: 1 RTT (~30ms)
Total: ~30ms per request

WebSocket Message (after connection):

Frame transmission: < 1ms on fast networks
Total: ~1-5ms end-to-end

WebSocket's latency advantage comes from eliminating per-message handshaking. For applications with frequent messages, this compounds dramatically.

Latency Comparison by Workload
Scenario	HTTP Latency	WebSocket Latency	Winner
Single API call	30-50ms	N/A (overkill)	HTTP
10 messages / minute	30-50ms each	1-5ms each	Marginal WebSocket
1 message / second	30-50ms each	1-5ms each	WebSocket
10 messages / second	30-50ms each (pooled)	1-5ms each	Clear WebSocket
Real-time streaming	Long-poll: ~100ms gaps	< 10ms	Strong WebSocket

Bandwidth Analysis:

HTTP headers dominate overhead for small messages:

Typical HTTP Request:

GET /api/status HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0...
Accept: application/json
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: session=abc123...
Authorization: Bearer eyJhbGc...

Size: 500-2000 bytes

WebSocket Frame:

[2-byte header] + [4-byte mask] + [payload]

Size: 6-14 bytes overhead

For a 100-byte payload:

HTTP: 600-2100 bytes (6-21x overhead)
WebSocket: 106-114 bytes (6-14% overhead)

Bandwidth Calculation Example
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
// Scenario: Real-time dashboard updating every second for 1000 users
// Each update: 200 bytes of data
 
// ═══════════════════════════════════════════════════════════════
// HTTP POLLING
// ═══════════════════════════════════════════════════════════════
 
const httpOverheadPerRequest = 800;  // Conservative estimate
const payloadSize = 200;
const usersCount = 1000;
const updatesPerMinute = 60;
 
const httpBytesPerUser = (httpOverheadPerRequest + payloadSize) * updatesPerMinute;
// = 1000 * 60 = 60,000 bytes/user/minute
 
const httpTotalPerMinute = httpBytesPerUser * usersCount;
// = 60,000 * 1000 = 60,000,000 bytes/minute = ~60 MB/minute
 
// Plus: client sends request headers too
const httpClientOverhead = 600 * updatesPerMinute * usersCount;
// = 600 * 60 * 1000 = 36,000,000 bytes/minute = ~36 MB/minute
 
// Total HTTP: ~96 MB/minute = ~1.6 MB/second
 
 
// ═══════════════════════════════════════════════════════════════
// WEBSOCKET PUSH
// ═══════════════════════════════════════════════════════════════
 
const wsOverheadPerMessage = 8;  // Frame header + mask
const payloadSize = 200;
const usersCount = 1000;
const updatesPerMinute = 60;
 
const wsBytesPerUser = (wsOverheadPerMessage + payloadSize) * updatesPerMinute;
// = 208 * 60 = 12,480 bytes/user/minute
 
const wsTotalPerMinute = wsBytesPerUser * usersCount;
// = 12,480 * 1000 = 12,480,000 bytes/minute = ~12.5 MB/minute
 
// Total WebSocket: ~12.5 MB/minute = ~0.2 MB/second
 
 
// COMPARISON
// HTTP: 96 MB/minute
// WebSocket: 12.5 MB/minute
// WebSocket uses 87% less bandwidth

HTTP/2 Reduces the Gap

HTTP Alternatives for Real-Time

Short Polling:

The simplest approach—client requests updates at regular intervals:

setInterval(async () => {
  const response = await fetch('/api/updates');
  const data = await response.json();
  if (data.hasUpdates) {
    handleUpdates(data.updates);
  }
}, 5000); // Every 5 seconds

Pros: Simple, works everywhere, easy debugging, stateless Cons: Latency up to polling interval, wasted requests when no updates, server load scales with users × frequency

Best for: Low-frequency updates (dashboards refreshing every minute), situations where near-real-time isn't required

Long Polling:

Client sends request, server holds it until data is available:

async function longPoll() {
  try {
    const response = await fetch('/api/updates?timeout=30');
    const data = await response.json();
    handleUpdates(data.updates);
  } catch (error) {
    await sleep(1000); // Brief pause before retry
  }
  longPoll(); // Immediately reconnect
}
longPoll();

Pros: Near-instant updates, works through all proxies, no special protocol Cons: Server holds connections (resource usage), HTTP overhead per update, unidirectional

Best for: Moderate real-time needs where WebSocket isn't supported or is overkill

Server-Sent Events (SSE):

Dedicated HTTP streaming from server to client:

// Client
const evtSource = new EventSource('/api/stream');
evtSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  handleUpdate(data);
};

// Server (Node.js)
app.get('/api/stream', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  
  const sendEvent = (data) => {
    res.write(`data: ${JSON.stringify(data)}\n\n`);
  };
  
  // Subscribe to updates
  eventBus.on('update', sendEvent);
  req.on('close', () => eventBus.off('update', sendEvent));
});

Pros: Simple API, automatic reconnection, event IDs for resumption, works with HTTP/2 Cons: Server-to-client only, limited browser connections (~6 per domain), text-only (base64 for binary)

Best for: Live feeds, notifications, dashboards—anywhere server pushes but client doesn't need to push back

HTTP Real-Time Technique Comparison
Technique	Direction	Latency	Complexity	Best Use Case
Short Polling	Client → Server	Up to interval	Very Low	Infrequent updates OK
Long Polling	Server → Client	~Instant	Low	Moderate real-time, legacy support
SSE	Server → Client	~Instant	Low	Live feeds, notifications
WebSocket	Bidirectional	~Instant	Medium-High	Chat, gaming, collaboration

SSE is Often Enough

Infrastructure Compatibility

HTTP's universal support is a major practical advantage. WebSocket, while widely supported, introduces compatibility challenges that should factor into your decision.

Infrastructure Considerations

•Proxies: Some corporate proxies, especially older ones, don't properly forward WebSocket upgrades. They may hold connections, timeout unexpectedly, or block entirely. HTTP works through everything.
•Load Balancers: Layer 4 (TCP) load balancers work with WebSocket. Layer 7 (HTTP) load balancers need explicit WebSocket support. Session affinity configuration required.
•CDNs: Most CDNs don't proxy WebSocket (they're designed for cacheable content). You'll need separate infrastructure or CDN WebSocket add-ons.
•API Gateways: Support varies. AWS API Gateway supports WebSocket. Others may not, or may impose limitations.
•Serverless: WebSocket on serverless is complex. AWS API Gateway + Lambda works but has quirks. Many serverless platforms don't support WebSocket.
•Monitoring: HTTP requests are easily logged and monitored. WebSocket connections require different tooling for traffic analysis.

Platform Support Matrix
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
// ═══════════════════════════════════════════════════════════════
// WEBSOCKET SUPPORT BY PLATFORM
// ═══════════════════════════════════════════════════════════════
 
LOAD BALANCERS
├─ AWS ALB:           ✅ Full support (connection stickiness available)
├─ AWS NLB:           ✅ Full support (TCP level)
├─ GCP Load Balancer: ✅ Full support
├─ Azure LB:          ✅ Full support
├─ NGINX:             ✅ Full support (requires configuration)
├─ HAProxy:           ✅ Full support
└─ Classic ELB:       ⚠️ Limited (use TCP mode, not HTTP)
 
API GATEWAYS
├─ AWS API Gateway:   ✅ WebSocket APIs supported
├─ Kong:              ✅ Full support with plugins
├─ Azure API Mgmt:    ✅ Full support
├─ Apigee:            ⚠️ Limited support
└─ Generic reverse proxy: ⚠️ Configuration required
 
SERVERLESS
├─ AWS Lambda:        ⚠️ Via API Gateway only, connection mgmt separate
├─ Azure Functions:   ⚠️ Via SignalR service
├─ GCP Cloud Run:     ✅ Full support (with caveats)
├─ Cloudflare Workers:✅ Durable Objects for state
└─ Vercel:            ❌ Not supported (use third-party)
 
CDNS
├─ Cloudflare:        ✅ WebSocket proxying supported
├─ Fastly:            ✅ Supported
├─ AWS CloudFront:    ⚠️ Limited (origin only, not edge)
└─ Akamai:            ✅ Supported with configuration
 
BROWSERS
├─ Chrome:            ✅ Since v4
├─ Firefox:           ✅ Since v11
├─ Safari:            ✅ Since v6
├─ Edge:              ✅ Since v12
├─ IE:                ⚠️ IE10+ only
└─ Mobile browsers:   ✅ Generally good support

Corporate Network Challenges

Operational Complexity

HTTP's statelessness makes it operationally simple. WebSocket's statefulness introduces complexity across the entire operations lifecycle:

HTTP Operations

•Deploy updates: Stop process, start new one. In-flight requests may fail, clients retry automatically.
•Scale up: Add servers to load balancer pool. Traffic distributes immediately.
•Scale down: Remove server, let connections drain naturally. Simple.
•Debug: Standard HTTP logging. Request/response pairs. Easy to trace.
•Monitor: Request counts, latency percentiles, error rates. Well-established patterns.

WebSocket Operations

•Deploy updates: Must drain connections gracefully. Clients reconnect (connection storm). State may be lost.
•Scale up: New server joins pool but existing connections stay put. Uneven distribution.
•Scale down: Must migrate connections or force reconnect. Coordinated drain needed.
•Debug: Bidirectional message streams. Harder to trace. Stateful context needed.
•Monitor: Connection counts, message rates, connection durations. Different tooling required.

Deployment challenges:

Rolling deployments with WebSocket require careful orchestration:

Graceful shutdown signal — New server version starts receiving new connections
Drain period — Old server stops accepting new connections, keeps existing
Force disconnect — After drain timeout, close remaining connections with appropriate code (1012 Service Restart)
Reconnection storm — All disconnected clients reconnect simultaneously
State recovery — Clients must re-establish subscriptions, catch up on missed messages

This complexity is manageable but requires planning that HTTP deployments don't need.

Graceful Shutdown Implementation
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
// Graceful WebSocket server shutdown for deployments
 
class WebSocketServer {
    private connections = new Set<WebSocket>();
    private isShuttingDown = false;
    
    handleConnection(ws: WebSocket) {
        if (this.isShuttingDown) {
            // Reject new connections during shutdown
            ws.close(1013, 'Try again later');
            return;
        }
        
        this.connections.add(ws);
        ws.on('close', () => this.connections.delete(ws));
    }
    
    async gracefulShutdown(drainTimeoutMs: number = 30000) {
        console.log('Starting graceful shutdown...');
        this.isShuttingDown = true;
        
        // Notify clients to prepare for reconnection
        for (const ws of this.connections) {
            if (ws.readyState === WebSocket.OPEN) {
                ws.send(JSON.stringify({ 
                    type: 'server_shutdown', 
                    reconnectAfterMs: 5000 
                }));
            }
        }
        
        // Wait for drain period
        const drainStart = Date.now();
        while (this.connections.size > 0) {
            if (Date.now() - drainStart > drainTimeoutMs) {
                console.log(`Force closing ${this.connections.size} connections`);
                break;
            }
            await sleep(1000);
            console.log(`Waiting for ${this.connections.size} connections to close...`);
        }
        
        // Force close remaining connections
        for (const ws of this.connections) {
            ws.close(1012, 'Service restart');
        }
        
        console.log('Shutdown complete');
    }
}
 
// Usage: Listen for SIGTERM from orchestrator
process.on('SIGTERM', async () => {
    await server.gracefulShutdown(30000);
    process.exit(0);
});

Decision Framework

With a thorough understanding of the trade-offs, we can establish a decision framework for choosing between WebSocket and HTTP-based approaches.

Start with HTTP, graduate to WebSocket:

The guiding principle is to use the simplest solution that meets requirements. WebSocket should be a deliberate choice, not a default.

Use regular HTTP when:

Updates are infrequent (< 1/minute)
Latency of seconds is acceptable
Request-response fits naturally
You want maximum infrastructure compatibility
Serverless is your deployment model

Use SSE when:

Server needs to push to client frequently
Client-to-server is infrequent (can use separate HTTP requests)
You want simpler implementation than WebSocket
Built-in reconnection is valuable

Use WebSocket when:

Both parties send messages frequently
Sub-second latency is required
Binary data efficiency matters
State must be maintained across messages
Real-time bidirectional is core to the feature

Decision Flowchart
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
// PROTOCOL SELECTION DECISION TREE
 
                        START
                          │
                          ▼
            ┌──────────────────────────────┐
            │ Does the server need to      │
            │ push updates to the client?  │
            └─────────────┬────────────────┘
                          │
              no ─────────┼───────── yes
              │           │           │
              ▼           │           ▼
          HTTP REST       │   ┌───────────────────────────┐
          (polling if     │   │ Does the client also      │
           needed)        │   │ send frequent messages?   │
                          │   └───────────┬───────────────┘
                          │               │
                          │   no ─────────┼───────── yes
                          │   │           │           │
                          │   ▼           │           ▼
                          │  SSE          │   ┌───────────────────────────┐
                          │  (or long     │   │ Is sub-second latency    │
                          │   polling)    │   │ required?                │
                          │               │   └───────────┬───────────────┘
                          │               │               │
                          │               │   no ─────────┼───────── yes
                          │               │   │           │           │
                          │               │   ▼           │           ▼
                          │               │  HTTP/2 with  │       WebSocket
                          │               │  bidirectional│
                          │               │  streaming    │
                          │               │  (or consider │
                          │               │   WebSocket)  │
 
 
// COMMON USE CASE MAPPINGS
 
Chat application:           → WebSocket (bidirectional, real-time)
Live notifications:         → SSE or WebSocket (server push)
Real-time dashboard:        → SSE (server push, infrequent client input)
Collaborative editing:      → WebSocket (bidirectional, state sync)
Live sports scores:         → SSE (server push)
Online gaming:              → WebSocket (bidirectional, low latency)
Stock ticker:               → SSE or WebSocket (depends on trade capability)
IoT device control:         → WebSocket (bidirectional commands)
Comment section updates:    → Polling or SSE (low frequency)
Presence indicators:        → WebSocket (bidirectional heartbeats)

The Hybrid Approach

Case Studies: Protocol Choices in Practice

Let's examine how real systems make protocol choices, illustrating the decision framework in practice.

Case Study 1: Twitter/X Timeline

Requirements: Tweets appear in timeline in near-real-time; users compose tweets (infrequent client-to-server).

Decision: Uses HTTP polling with variable intervals. New tweets fetched every 15-60 seconds depending on activity. Notifications use push notifications (mobile) or polling (web).

Lesson: Even real-time-feeling features may not need WebSocket when near-real-time suffices.

Case Study 2: Figma Collaborative Design

Requirements: Multiple users edit simultaneously; cursor positions visible in real-time; changes appear instantly.

Decision: WebSocket for all interactive operations. Every cursor move, selection change, and edit transmits immediately.

Why WebSocket? True collaboration requires sub-second latency. Users expect to see others' cursors moving smoothly. High-frequency bidirectional data (every cursor move generates an event).

Lesson: When real-time collaboration is the core product, WebSocket complexity is justified.

Case Study 3: GitHub Actions Build Logs

Requirements: Stream build output as it happens; user watches build complete.

Decision: Server-Sent Events. Log lines stream from server as they're produced.

Lesson: SSE is often the right choice for server-push-only features.

Protocol Usage by Company/Feature
Company	Feature	Protocol	Rationale
Slack	Messages	WebSocket	Real-time chat, bidirectional
Slack	API calls	HTTP	Standard request-response
Stripe	Webhooks	HTTP callbacks	Event delivery, async
Discord	Voice/Video	WebSocket + WebRTC	Real-time streaming
Notion	Collaboration	WebSocket	Real-time sync
Netflix	Playback position	HTTP	Infrequent sync
Trading platforms	Order book	WebSocket	Sub-ms latency required

Summary: Choosing the Right Tool

The choice between WebSocket and HTTP is a trade-off, not a competition. Each protocol excels in different scenarios. Let's consolidate the key insights:

Key Takeaways

•HTTP optimizes for transactions, WebSocket for conversations — Choose based on your communication pattern, not hype.
•WebSocket excels at low-latency, high-frequency, bidirectional messaging — Chat, gaming, collaborative editing are natural fits.
•SSE is often overlooked but powerful — For server-push without client-push, SSE is simpler than WebSocket with similar performance.
•HTTP/2 narrows the efficiency gap — Header compression and multiplexing reduce HTTP overhead significantly.
•Infrastructure compatibility favors HTTP — Proxies, CDNs, serverless, and monitoring tools work better with HTTP.
•Operational complexity is real — WebSocket's statefulness complicates deployments, scaling, and debugging.
•Start simple, graduate when needed — Default to HTTP; use WebSocket when requirements demand it.
•Hybrid approaches are common — Use HTTP for standard APIs, WebSocket for real-time features.

What's next:

Page Complete

4 / 5