Many products need to show updates without making the user refresh the page: chat messages, build status changes, payment updates, cursors in a shared document, or AI tokens streaming back from a model.

Plain HTTP request-response is awkward for this. The server normally cannot send anything until the client asks for it.

Long polling keeps normal HTTP. The client asks for updates, and the server holds the request open until there is data or the request times out.

WebSockets start as HTTP, then upgrade into one long-lived connection where either side can send messages at any time.

Neither option is always better.

Long polling is simpler and works almost anywhere HTTP works. WebSockets are better for frequent two-way messages, but they take more care to run in production. Many real systems use both, sometimes in the same product.

This chapter covers how long polling and WebSockets work and when to choose each.

The simplest update strategy is short polling:

Short polling is easy, but it creates a bad trade-off.

Poll often, and most requests return nothing. Poll slowly, and users see stale data.

For example, 100,000 clients polling every 5 seconds creates about 20,000 requests per second even when nothing has changed.

Those empty requests are not free. They still use CPU, network bandwidth, logs, TLS and session handling, rate-limit checks, and often database or cache reads.

Long polling and WebSockets reduce that waste in different ways.

Long polling is HTTP polling where the server waits before it responds.

The client sends a request with a cursor such as after=42. The cursor means "send me events after event 42."

The server checks for newer events. If it finds any, it responds right away. If it does not, it keeps the request open until a new event arrives or the request times out.

After every response, the client sends the next request.

Long polling is not one permanent connection. It is a chain of HTTP requests. Each request may wait before returning.

Long Polling Client Example

A long polling client is just a loop:

The code below shows that loop in JavaScript.

The cursor is important. Without it, the client can miss events during reconnect gaps, timeouts, mobile network changes, or page reloads.

Strengths of Long Polling

The biggest advantage is that long polling works over normal HTTP. It usually fits existing proxies, authentication, load balancers, and server frameworks without special setup.

Client behavior stays simple too: send a request, process the response, repeat. That makes long polling a good choice for occasional updates such as notifications, status changes, comments, and low-volume feeds.

Long polling is also a useful fallback when WebSockets are blocked or not worth the extra work to run. It avoids keeping a permanent two-way channel open when the client only needs to receive updates from the server.

Trade-offs of Long Polling

The cost of that simplicity shows up under load. Each active client usually has one waiting request, so the server may hold many connections at once.

Every response is followed by a new request, which adds extra work. The small gap between requests means you need a cursor and stored events so clients can catch up safely.

Server resources are the other concern. Thread-per-request servers struggle when many requests are waiting, because each waiting request may hold a thread.

Timeouts also need care. The client, server, proxy, and load balancer should agree on how long a request may stay open.

Long polling scales best on async or event-driven servers. Holding 100,000 requests open with one operating system thread per request is a bad plan.

WebSockets provide one long-lived, two-way message channel between a client and a server.

The connection starts as HTTP. The client asks to upgrade. If the server accepts, both sides switch to the WebSocket protocol and keep the connection open.

Once open, either side can send messages until the connection closes.

WebSocket Client Example

On the client side, a WebSocket usually means opening a connection and attaching handlers for connection events and messages.

Notice how different this shape is from the polling loop above.

Production clients need more than this small example: authentication, heartbeats, reconnects with delay, duplicate handling, and a way to catch up on messages missed while disconnected.

Strengths of WebSockets

Each message has low overhead because it does not need a full HTTP request and response. The connection is two-way, so the client and server can both send messages whenever they need to.

That keeps latency low when updates are frequent and interactive.

This fits session-like interactions naturally. Chat, collaboration, games, and live control panels all benefit from keeping the same channel open. One connection can carry many small messages efficiently, which matters for high-frequency streams.

Trade-offs of WebSockets

The cost shows up in day-to-day operations.

Servers must track connections, heartbeats, disconnects, and reconnects. That means the gateway layer becomes stateful: the system needs to know which users are connected to which nodes.

Load balancing is harder because each connection stays attached to one node while it is open. Deploys also need care, because live connections should move off a node before it shuts down.

WebSockets also do not store messages for you. They are a delivery mechanism, not a message broker. If the client disconnects, messages can be missed unless you store them and replay them later.

Slow clients can also become a problem. If a client cannot read messages fast enough, server buffers can grow and consume memory.

Infrastructure support is worth checking early. Proxies, gateways, idle timeouts, and corporate networks can all affect WebSocket behavior.

WebSockets enable rich two-way communication, but they move the system from simple request handling toward stateful connection management.

Long polling and WebSockets both create load on the server, but the load looks different.

At small scale, either can work. At large scale, the details of running the system matter more than the protocol name.

Long Polling at Scale

Long polling at scale needs async request handling so each waiting request does not tie up a thread.

Reads should use cursors and stored events, so clients can recover anything they missed. The server also has to clean up waiting requests when clients disconnect.

Timeouts should be shorter than proxy idle timeouts. Otherwise, a proxy may silently close the request before your app expects it.

Retries should include a little randomness, often called jitter, so thousands of clients do not reconnect at the exact same moment.

Per-user or per-topic limits help prevent one busy tenant from using too much capacity.

The main risk is holding too many waiting requests inefficiently.

WebSockets at Scale

WebSockets at scale need a way to track live connections. The system needs to know which user is connected to which node.

They also need heartbeats, idle timeouts, reconnect logic, and client code that can resubscribe after reconnecting.

Message ordering and duplicate handling become important. So does protecting the server from slow clients that cannot keep up.

Deployments need node draining, which means moving live connections away from a node before shutting it down.

A broker or publish/subscribe layer is often needed to route each message to the node that owns the right connection.

The main risk is treating a WebSocket gateway like a stateless HTTP service. It is not. It owns live connection state.

Neither long polling nor WebSockets automatically guarantee reliable delivery.

Clients disconnect. Mobile networks change. Browser tabs sleep. Servers deploy. Proxies close idle connections. Users open the same account on multiple devices.

So design a recovery path.

A few practices help.

Give each event a stable ID. Store the event before trying to deliver it in real time. Let clients reconnect with lastEventId or an equivalent cursor so they can ask for anything they missed.

Make handlers safe to run more than once, because retries and reconnects can create duplicate messages.

Use heartbeats to detect broken connections. When the client thinks it may have missed something, let it reload the latest state from the API.

For many systems, real-time delivery should be treated as a notification path, not the source of truth. The database, event log, or API remains the place to check for the correct state.

Long polling is a good choice when updates are occasional: notifications, job status, build status, and simple alerts.

It also fits when you want HTTP simplicity and your existing auth, proxies, and deployment tools already work.

If the client only receives updates and does not need full two-way interaction, long polling fits well.

Some environments handle normal HTTP more reliably than upgraded connections, so compatibility can decide the issue. Long polling also works well as a fallback when WebSockets fail or are blocked.

WebSockets become the better fit when messages are frequent: chat, multiplayer state, collaboration, trading screens, or live dashboards.

They also matter when both sides send events, such as typing indicators, cursor movement, game input, or control commands.

Applications that need low latency benefit because repeated HTTP requests start to add noticeable overhead. Session-oriented products fit naturally too, where users join rooms, subscribe to channels, or maintain presence.

The cost shows up in day-to-day operations. Pick WebSockets when you can run stateful connection infrastructure with heartbeats, routing, draining, backpressure, and replay as part of the design.

For one-way server updates in a browser, Server-Sent Events is worth considering. AI token streaming to a browser is usually handled by SSE or streaming HTTP. WebSockets are more useful when the client also sends live events.

Durable event processing belongs in a queue, stream, or event log, not in a WebSocket alone.

Long polling and WebSockets are not the only ways to send updates between client and server.

The best fit usually depends on two questions:

Server-Sent Events

Server-Sent Events, or SSE, lets a server stream events to a browser over HTTP.

SSE is one-way: server to client. That makes it simpler than WebSockets for feeds, notifications, progress updates, and AI token streaming where the browser only needs to receive output.

Streaming HTTP

For some APIs, the server can send the response a piece at a time using chunked transfer or streaming response APIs.

This is common for AI responses, exports, logs, and progress output. It keeps the normal request-response shape, but it avoids waiting for the full result before sending data.

MQTT

MQTT is a lightweight publish/subscribe protocol often used for IoT and device messaging.

It is useful when devices need efficient messaging over unreliable networks, often with broker-managed topics and delivery options.

WebRTC and WebTransport

For media or low-latency peer communication, WebSockets are often the wrong tool.

Use WebRTC for audio, video, screen sharing, and peer-to-peer media. WebTransport can be useful for low-latency client-server streams where it is supported, but it is operated differently from WebSockets.

Use long polling when you need simple near-real-time updates over ordinary HTTP.

Use WebSockets when you need frequent, low-latency, two-way messages and you are prepared to run stateful connection infrastructure.

Use SSE or streaming HTTP when the server only needs to stream data to the browser.

And for all of them: store important events somewhere safe. The real-time channel delivers messages. It is not the system of record.

Both long polling and WebSockets let a server deliver updates without making the user refresh, but they make different trade-offs.

Long polling keeps the normal HTTP request-response model. The server holds each request open until data is ready or the request times out. Then the client immediately opens another request.

WebSockets upgrade an HTTP connection into one long-lived two-way channel where either side can send messages at any time.

Long polling is simple to operate because it reuses standard HTTP infrastructure, but frequent updates create extra requests and overhead.

WebSockets give frequent, low-latency, two-way messaging, but you have to operate stateful connection infrastructure such as gateways, heartbeats, and reconnect logic.

When the server only needs to stream data toward the browser, SSE or streaming HTTP is often a better fit than either.

Use long polling for simple near-real-time updates over plain HTTP. Use WebSockets when you need frequent two-way messages and can run the connection infrastructure.

For all of them, store important events somewhere safe, because a real-time connection is a delivery path, not a database.