WebSocket vs SSE vs Polling: Choosing Your Real-Time Communication Protocol

Real-time web features—live chat, collaborative editing, notifications, live dashboards—require pushing data from server to client without the client asking for it repeatedly. The three dominant approaches—polling, Server-Sent Events (SSE), and WebSocket—offer different trade-offs in latency, complexity, browser support, and infrastructure requirements.

Polling: The Simplest Fallback

Polling is the oldest technique: the client sends periodic HTTP requests to check for new data. Short polling sends requests every few seconds. Long polling holds the request open until the server has data to return or a timeout expires:

// Short polling (every 5 seconds)
async function pollUpdates() {
  const response = await fetch('/api/notifications');
  const notifications = await response.json();
  updateUI(notifications);
}

setInterval(pollUpdates, 5000);

// Long polling
async function longPoll() {
  const response = await fetch('/api/notifications/long');
  const notifications = await response.json();
  updateUI(notifications);
  longPoll();  // Immediately start the next poll
}

Polling's advantages: it works over any HTTP infrastructure, requires no server-side protocol upgrades, and is trivially debuggable with curl. Every load balancer, CDN, and proxy handles polling without configuration changes.

The disadvantages are equally clear: short polling wastes bandwidth and server resources on requests that return no data. Long polling keeps connections open on the server, consuming memory for each idle client. At scale (10,000+ concurrent users), polling's inefficiency becomes a significant cost.

Server-Sent Events: One-Way Push over HTTP

SSE sends real-time updates from server to client over a single, long-lived HTTP connection. The client subscribes with EventSource, and the server streams text/event-stream responses:

// Client
const eventSource = new EventSource('/api/events');

eventSource.addEventListener('order.update', (event) => {
  const order = JSON.parse(event.data);
  updateOrderStatus(order);
});

eventSource.addEventListener('notification', (event) => {
  const notification = JSON.parse(event.data);
  showToast(notification);
});

eventSource.onerror = (err) => {
  console.error('SSE connection error', err);
  // EventSource automatically reconnects with last-event-id header
};

# Server (FastAPI)
from fastapi import FastAPI, Request
from sse_starlette.sse import EventSourceResponse

app = FastAPI()

@app.get('/api/events')
async def event_stream(request: Request):
    async def event_generator():
        async for message in redis.pubsub().listen():
            if await request.is_disconnected():
                break
            yield {
                'event': message['type'],
                'data': message['data'],
            }
    return EventSourceResponse(event_generator())

SSE advantages over polling: persistent connection eliminates per-request overhead, automatic reconnection with last-event tracking, and native browser support for EventSource (Chrome, Firefox, Safari, Edge—all modern browsers).

SSE limitations: unidirectional (server to client only), limited to 6 concurrent connections per domain (browser limit), and poor performance through HTTP/1.1 proxies that buffer responses. HTTP/2 eliminates the connection limit and mitigates the buffering issue.

WebSocket: Full-Duplex Communication

WebSocket establishes a persistent, bidirectional channel over a single TCP connection. Both client and server can send messages at any time:

// Client
const ws = new WebSocket('wss://api.example.com/ws');

ws.onopen = () => {
  ws.send(JSON.stringify({
    type: 'subscribe',
    channel: 'order.updates',
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.type === 'order.update') {
    updateOrderStatus(data.payload);
  }
};

ws.onclose = () => {
  // Reconnect with exponential backoff
  setTimeout(() => connectWebSocket(), Math.min(retryCount * 1000, 30000));
};

ws.onerror = (err) => {
  console.error('WebSocket error:', err);
};

# Server (FastAPI with WebSocket)
from fastapi import WebSocket, WebSocketDisconnect

@app.websocket('/ws')
async def websocket_endpoint(websocket: WebSocket):
    await websocket.accept()
    try:
        while True:
            data = await websocket.receive_json()
            if data['type'] == 'subscribe':
                await subscribe_to_channel(websocket, data['channel'])
            elif data['type'] == 'message':
                await broadcast_message(data['channel'], data['payload'])
    except WebSocketDisconnect:
        await cleanup_connection(websocket)

WebSocket is the only option that supports true bidirectional, low-latency communication. Latency is typically 10–50 ms end to end, limited only by network round-trip time. The protocol supports binary frames, making it efficient for high-frequency updates.

Infrastructure Considerations

WebSocket and SSE require infrastructure that supports long-lived connections:

• Load balancers: must support sticky sessions or allow WebSocket upgrade headers. AWS ALB and Nginx both handle this natively.
• Horizontal scaling: WebSocket servers need a pub/sub backend (Redis, Kafka) to broadcast messages across instances. A message sent to one server must reach all connected clients.
• Connection limits: Each WebSocket connection consumes a file descriptor and memory (~20–50 KB per idle connection). Plan capacity accordingly.

# Nginx WebSocket proxy configuration
map $http_upgrade $connection_upgrade {
    default  upgrade;
    ''       close;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    location /ws/ {
        proxy_pass http://websocket_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_read_timeout 86400s;
    }
}

Decision Matrix

| Requirement | Polling | SSE | WebSocket | |---|---|---|---| | Latency | 1–30s (configurable) | 10–100ms | 10–50ms | | Bidirectional | Yes (separate requests) | No (server→client only) | Yes | | Browser support | Universal | ~96% modern browsers | ~97% modern browsers | | Auto-reconnect | Yes (trivial) | Built-in | Custom implementation | | Binary data | No (base64 only) | No | Yes | | Infrastructure complexity | None | Low | Moderate | | Scale cost (10K clients) | High bandwidth | Low bandwidth | Low bandwidth |

For most use cases, start with SSE for server-to-client push (notifications, dashboards, live feeds) and add WebSocket only for bidirectional requirements (chat, collaborative editing, gaming). Use polling as a fallback when SSE or WebSocket aren't available.

Build Real-Time Features with SoniNow

Choosing the right real-time protocol is the foundation of a responsive, scalable web application. Our team at SoniNow helps select and implement the real-time communication architecture that fits your use case and infrastructure.