Polling beats websockets sometimes. The Clinical OPD example.

Engineers conditioned by chat apps reach for websockets when they see the word "realtime." Most of the time, polling at fifteen seconds is the correct answer — and the operational complexity it saves is the actual value of the choice.

We built Clinical OPD for an independent clinic in Bangalore. Six patients per hour at peak. Two doctors. A coordinator running the front desk. The brief asked for a queue view that updates "in real time" — the coordinator wanted to see, on her dashboard, when a patient was added by reception or moved into consultation by the doctor without refreshing the page.

Three engineers reflexively suggested websockets. One suggested server-sent events. Nobody initially suggested polling. We went around the table for an hour. We shipped polling. Fifteen-second interval. Done.

It is, by a comfortable margin, the right architecture for this clinic.

Why "realtime" is rarely realtime

The word "realtime" has a precise meaning in some domains — trading floors, multiplayer games, telemetry pipelines — and a much looser meaning everywhere else. When a coordinator at a six-patient-an-hour clinic asks for "realtime," she means "I don't want to manually refresh the page." She does not mean "I need updates within 200 milliseconds."

At fifteen-second polling, the longest delay between a state change and the coordinator seeing it is fifteen seconds. In a clinic where individual patient interactions take three to seven minutes, fifteen seconds is invisible. She experiences the dashboard as alive. Nobody is timing it with a stopwatch.

Engineers conditioned by chat apps and trading systems forget that those domains chose their architecture because of strict latency requirements. Most other domains don't have those requirements and shouldn't pay their cost.

What websockets actually cost

Websockets are not free. They require a long-lived connection per client. They need a reconnect strategy. They need a heartbeat. They need a fallback for networks that block them. They need careful thought about state synchronization on reconnect — what the server thinks the client knows versus what the client actually knows.

In production they fail in distinctive ways. Mobile networks drop the connection. Corporate firewalls block them. Load balancers terminate them at idle thresholds. Every team that ships websockets eventually ships a parallel polling layer as a fallback. You pay the cost of both architectures.

For a chat product, this cost is unavoidable; the user expectation is sub-second message delivery. For a clinic queue updating six times per hour, the cost is pure operational drag.

When polling stops being the right answer

There is a threshold. Polling stops working when one of three things is true. First, the data changes more than a few times per second and the polling cost dominates. Second, the user expectation is genuinely sub-second — a chat message, a stock quote, a multiplayer move. Third, the client count is large enough that the request volume of polling overwhelms the server.

None of these are true for a six-patient-an-hour clinic. None of these are true for most internal operational dashboards. Most B2B SaaS dashboards. Most admin tools. Most queue views. Most KPI surfaces.

The honest question is not "polling or websockets" — it's "what does the user actually experience as alive." Fifteen seconds is alive. One second is alive. Two hundred milliseconds is alive and expensive. Pick the cheapest layer that delivers alive.

What we'd start with on day one

Polling. Pick an interval that matches the user's tolerance — fifteen seconds is a fine starting point for most operational dashboards. Use ETags or cheap conditional GETs to make the polling cheap when nothing changed. Reach for SSE if you need server-pushed events with low overhead. Reach for websockets only when the latency requirement is genuinely sub-second and you have the operational appetite to run that infrastructure.

The answer to 'do we need websockets' is almost always no.

Clinical OPD is in production at the clinic. We can scope a multi-portal operational platform — coordinator, clinician, support roles — that picks the right realtime tier for the actual operation, not the engineer's instinct.