Real-time API Patterns

Long-polling, Server-Sent Events, and WebSockets — pick based on direction, frequency, and client capability.

How It Works

Real-time APIs push updates from server to client, but there's no single right pattern. Long-polling (client holds a request open, server responds when data arrives, client immediately re-polls): simplest, works over plain HTTP, but has high per-event overhead and pins server resources holding connections. Server-Sent Events (SSE): server pushes over HTTP, one-way (server → client), auto-reconnects, works through standard HTTP infrastructure including CDNs and proxies. WebSocket: full bidirectional, lowest overhead per message after connection setup, requires an explicit upgrade handshake, often needs sticky sessions at the load balancer. Rule of thumb: SSE for read-only update streams (feeds, dashboards, stock tickers), WebSocket for interactive features (chat, collaborative editing, games), long-polling only as a fallback when infrastructure can't support the other two.

Real-World Example

Slack uses WebSockets for message send/receive because the flow is bidirectional — you type, others type, everyone's clients update live. But for Slack's Grid Directory feature (showing real-time workspace membership updates), they use Server-Sent Events — clients only need to receive, not send, and SSE reuses existing HTTP infrastructure with less operational cost than maintaining WebSocket sticky sessions. Matching the pattern to the actual direction of data flow saves infrastructure cost and simplifies failure handling.