Updates that arrive
without the page being refreshed
A feature that needs to feel live, a chat, a notification, a dashboard number ticking up, has two options. It either polls the server every few seconds and feels laggy, or it holds a websocket connection open and pushes updates the moment they happen. We built the event protocol behind a closed social network's live reputation and activity feed on exactly this kind of real-time connection.
What a websocket actually does differently
A websocket is a persistent, two-way connection between a client and a server. It stays open, instead of opening and closing for every request. That lets the server push an update the instant it happens, instead of waiting for the client to ask.
This is the infrastructure behind live chat, real-time notifications and live dashboards. It covers anything else that should update on its own, without the user refreshing or the app polling on a timer.
When this earns its cost, and when it is overkill
It earns its cost when an update genuinely needs to feel instant: a chat message, a live bid, a reputation score changing as it happens.
We built the event protocol behind a closed premium social network’s live activity and reputation feed on exactly this kind of persistent connection. A feed that only updated on refresh would have undercut the whole premise of feeling alive.
It is the wrong tool, or at least overkill, when an update every ten or thirty seconds is genuinely fine. An order status that changes a few times a day does not need a persistent connection. A periodic poll gets the same practical result with far less infrastructure.
We recommend polling over websockets whenever it honestly covers the need. Websocket infrastructure carries a real ongoing operational cost that a simple poll does not.
How the server handles drops, bursts and scale
We start by confirming the feature actually needs push, not just a faster pull. That decision shapes everything after it.
When websockets are the right call, reconnect handling is a first-class part of the server, not an edge case. Mobile networks drop connections constantly, in elevators, on trains, switching between Wi-Fi and cellular. The client retries with backoff, and the server resyncs any state it missed during the gap, instead of silently losing messages.
Backpressure matters more than it looks like it should. A burst of events, a popular chat room, a trending item’s live bid count, can produce updates faster than a slow client can consume them. A server that ignores this either drops messages unpredictably or lets a buffer grow until the process runs out of memory.
We build explicit backpressure handling instead: batching or dropping intermediate updates in a controlled way when a client falls behind. We would rather design for that than discover it in production.
Scaling past one server needs a pub/sub layer. A websocket connection lives on the specific server instance that accepted it. An event published by one instance has to reach connections held by others, through Redis or an equivalent message bus.
We build this in from the start for anything expected to outgrow a single server. Retrofitting pub/sub onto a system built for one instance is a much bigger job than building it in early.
Where this needs extra care
Authentication needs to happen on the websocket connection itself, not just on the initial HTTP handshake. A connection that stays authenticated by a token that could have been revoked since the handshake is a real security gap. We close it explicitly.
Load testing matters more here than for a typical REST API. Too many concurrent open connections fails differently than too many sequential requests. We test against a realistic concurrent connection count before launch, not just functional correctness.
Some corporate networks and older infrastructure block websockets outright. A feature with no fallback for those networks just fails for those users. We build a polling fallback so it degrades gracefully instead.
What you pay for one server vs many
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Single-server real-time feature | from $3,000 | Chat or notification feed, reconnect handling, auth | 3 to 4 weeks |
| Scaled real-time system | from $7,000 | Pub/sub backend, horizontal scaling, load testing | 5 to 6 weeks |
Running cost is the websocket server plus the pub/sub layer. Typically $30 to $200 a month, depending on concurrent connections.
Where this fits in your stack
This pairs with GraphQL API when the same data needs both queries and live updates. It also pairs with push notifications infrastructure for updates that should reach a user even when they are not actively connected. See the development service page for our full build process.
For real examples, see the closed premium social network’s event protocol and the end-to-end encrypted messenger with a zero-storage relay.
Get in touch if a feature should feel live but currently just polls, and we will tell you honestly if websockets are worth the added infrastructure.
FAQ
How much does a real-time feature cost?
From $3,000 for a focused feature, live chat or a notification feed, with reconnect handling and basic scaling. That ships in 3 to 6 weeks. A feature that needs to scale across many server instances, with a pub/sub backend, runs $6,000 to $12,000.
Do we actually need websockets, or would polling work?
If the update genuinely needs to feel instant, a chat message, a live auction bid, a collaborative cursor, websockets are the right tool. If an update every ten or thirty seconds is genuinely fine, a simple polling interval is far less infrastructure to build and maintain. We recommend it over websockets whenever it is honestly enough.
What happens when a user's connection drops?
It happens constantly on mobile networks. We build reconnect logic as a core part of the feature, not an edge case. The client detects the drop and retries with backoff. The server then replays or resyncs any state the client missed, so a brief tunnel or elevator dead zone does not lose messages.
How does this scale past one server?
A websocket connection is held open on one specific server instance. Scaling to more than one instance needs a pub/sub layer, Redis or an equivalent, so an event published by one server reaches a connection held by another. We build this in from the start for anything expected to grow past a single instance's capacity.
Who owns the infrastructure?
You. The websocket server, the pub/sub configuration and the client code all run on your own infrastructure. We hand over load test results and a runbook for monitoring connection counts.