The Question Every Dashboard Has to Answer

A customer watching your web dashboard sees a temperature of 71 degrees. The device measured 78 degrees eleven seconds ago. Whether that gap is acceptable, invisible, or a safety problem is the entire design question behind real-time data delivery, and it should be answered with a number before anyone picks a transport.

The number is your acceptable staleness: the maximum age of displayed data that still lets the user do their job. Five minutes is fine for a soil moisture sensor. Two seconds is fine for a fleet map. Two hundred milliseconds is required for a live control interface where a slider moves a motor. That single figure, paired with your device count, determines the answer more than any architectural preference.

Polling: Simple, Predictable, Often Sufficient

The browser asks the server for current state every N seconds over ordinary HTTP. It is the default for a reason. It works through every proxy and corporate firewall, needs no special infrastructure, survives connection loss without any code, caches and load-balances normally, and any engineer can debug it with browser dev tools.

The costs are equally clear. Average latency is half your interval, so a 10-second poll shows data that is 5 seconds stale on average and 10 at worst. Most requests return nothing new, which is pure waste. And the request rate scales with users multiplied by frequency regardless of whether anything is happening.

Put numbers on it. One hundred concurrent dashboard users polling every 5 seconds is 20 requests per second, which a single small instance handles without noticing. Ten thousand users polling every 2 seconds is 5,000 requests per second, which is a real backend with real cost. Polling breaks on economics long before it breaks on capability.

Two refinements are worth knowing. Conditional requests with ETag or If-Modified-Since let unchanged responses return a 304 with no body, cutting bandwidth by an order of magnitude while leaving request count unchanged. Adaptive intervals, where the client backs off from 2 seconds to 30 seconds when the tab is hidden or the data has been static, cut load dramatically for almost no complexity.

Long Polling and Server-Sent Events

Long polling holds the request open until data changes or a timeout of 30 to 60 seconds fires, then the client immediately reconnects. Latency approaches real time while the API stays plain HTTP. The cost is a held connection per client, which requires an async server rather than a thread-per-request model.

Server-Sent Events is the underrated middle option. A single long-lived HTTP response streams events one way, server to client. The browser handles reconnection and event IDs automatically, it works over standard HTTP/2, and it is roughly a tenth the implementation effort of WebSockets. For a dashboard that only displays and never issues commands over the same channel, SSE is frequently the correct answer, with commands going out as ordinary POST requests.

WebSockets: A Real Channel, With Real Obligations

A WebSocket upgrades one HTTP connection into a persistent bidirectional stream. Sub-100-millisecond delivery, minimal per-message overhead of a few bytes rather than several hundred bytes of headers, and the server pushes only when something actually changed. For a fleet map, a live control panel, or a chart at 10 samples per second, nothing else is appropriate.

What teams underestimate is the operational surface that comes with it:

  • Connection state becomes your problem. Reconnect with exponential backoff and jitter, resume from the last received sequence number, and reconcile missed events after a gap. This is the bulk of the work and it is all client-side.
  • Heartbeats are mandatory. Load balancers and mobile carriers silently drop idle connections after 30 to 120 seconds. Ping every 20 to 30 seconds or your users see a frozen dashboard that looks live.
  • Sticky sessions or a broker. A connection lives on one server instance, so a message generated elsewhere has to be routed there, usually through Redis pub/sub, a managed WebSocket service, or a message bus.
  • Auth expires mid-stream. Tokens are validated at upgrade time and then the connection outlives them. Implement in-band re-authentication and server-initiated close.
  • Corporate networks interfere. Some proxies still mishandle upgrade requests, so a polling fallback is not optional for B2B customers.
  • Memory per connection. Budget roughly 10 to 50 KB of server memory per idle connection. Ten thousand concurrent connections is 100 to 500 MB before any application state.

Decision Rules for a Connected Product

Choose by required staleness and scale, in that order.

  • Staleness over 30 seconds. Poll. Anything else is over-engineering.
  • 5 to 30 seconds, display only. Poll with conditional requests and adaptive backoff.
  • 1 to 5 seconds, display only. Server-Sent Events.
  • Under 1 second, or bidirectional control. WebSockets.
  • Alarms and safety events. Push regardless of the dashboard transport, and deliver through a separate path such as mobile push or SMS gateway, because a user with the tab closed must still be reached.

Mixing transports is normal and usually right: SSE for the live tile row, plain REST for historical charts, and a WebSocket only on the one control screen that needs it. The dashboard content itself should follow from what operators must see, worked through in what an IoT device dashboard must show.

The Half of the System Behind the Screen

Transport to the browser is only the last hop. The device-to-cloud link is a separate decision with its own constraints, and a battery-powered sensor should not be holding a socket open to satisfy a dashboard; that tradeoff is the substance of MQTT vs HTTP for IoT.

Behind that, the ingest path has to absorb device reporting rates that have nothing to do with how often a human looks. Writing every sample into a relational table is the classic failure described in time-series databases for sensor data, and the fan-out problem, where one device event must reach many watching clients, is a core topic in scaling an IoT backend.

Cost follows architecture directly. Persistent connections do not fit the request-response billing model of most function platforms, which is a known limit discussed in serverless architecture for an IoT product, and either choice lands in the monthly figures in IoT cloud infrastructure cost.

Pick the Cheapest Thing That Meets the Requirement

Projects House sizes real-time architecture against your actual staleness requirement, device count, and concurrent-user forecast, then builds the simplest transport that clears it. Send your device count, update rate, and dashboard requirements through our contact form.