How WebSockets Work: Why Some Apps Update Live and Others Don't

Open a cricket score app during an IPL match and the numbers change the instant a ball is bowled. Open your bank's net banking page, though, and you have to hit refresh to see if a payment landed. Both are web pages talking to a server. So why does one feel alive and the other feel stuck in 2010?

The answer is a technology called WebSockets, and once you know what it is, you'll start noticing it everywhere — in your trading app, your food delivery tracker, and the little "typing..." indicator in WhatsApp Web.

The old way: asking over and over again

Regular web traffic runs on HTTP (HyperText Transfer Protocol), the request-response system that loads every normal webpage. Your browser asks a server for something, the server replies, and the connection closes. That's it — a one-shot conversation. If you want fresh data, your browser has to ask again.

For years, developers faked "live" updates with a trick called polling: the page quietly re-asks the server every few seconds, like a kid in the back seat asking "are we there yet?" on a loop. It works, but it's wasteful. Most of those requests come back with nothing new, yet the server still has to process each one, and your phone still burns battery and data making them.

A WebSocket doesn't ask "anything new?" every few seconds — it just gets told the moment there is.

What a WebSocket actually does differently

A WebSocket connection starts life as a normal HTTP request, then does something called a "protocol upgrade" — the browser and server agree to keep the underlying connection open instead of closing it after one reply. Once that handshake is done, either side can send data to the other at any time, with no need to ask first. The server can push a new stock price or score update to your phone the instant it happens, instead of waiting for your app to come knocking.

This is why it suits certain jobs so well:

• Live sports scores and commentary — the server pushes each update as it happens
• Chat and messaging — both sides need to send and receive instantly, not just the server pushing to you
• Trading and stock ticker apps — prices that are even a few seconds stale can cost real money
• Multiplayer games and collaborative tools — where every player or editor needs to see changes immediately
• Delivery and ride tracking — the little moving dot on the map updates without you refreshing anything

For a page that rarely changes — a news article, a product listing — plain HTTP is still perfectly fine and simpler to build. WebSockets earn their complexity only when the data genuinely needs to flow continuously in both directions.

Where you're already using this, probably daily

If you've used Zerodha, Groww, or any Indian trading app and watched prices tick up and down without touching your phone, that's a WebSocket feed from the exchange reaching your screen in close to real time. The same technology sits behind the live win-probability graphics on cricket apps during IPL season, the "order is being prepared" to "out for delivery" updates on Swiggy and Zomato, and the read receipts and typing indicators in WhatsApp Web and Telegram.

It also shows up in less obvious places. Customer support chat widgets on bank and e-commerce sites, the collaborative cursors you see when multiple people edit a Google Sheet at once, and multiplayer mobile games built by Indian studios all lean on this same always-open-connection idea rather than constant refreshing.

There's a regulatory angle here too, worth knowing if you build or manage any app that handles money or personal data. A WebSocket connection is still a data channel, and under India's Digital Personal Data Protection (DPDP) Act, any personal data flowing through it — chat messages, location pings, transaction updates — is just as much "processing" as data sent over regular HTTP. Encrypting it (the secure version is called WSS, the WebSocket equivalent of HTTPS) isn't optional if real user data is involved; it's a baseline expectation, not an advanced feature.

The trade-off nobody mentions in the demo

Keeping a connection open all the time isn't free. A server handling millions of simultaneous WebSocket connections needs to hold open resources for each one, which is a very different engineering problem than handling millions of quick, stateless HTTP requests that come and go. This is one reason apps with huge Indian user bases — think an IPL streaming app during a final, or a UPI-linked payment app — invest heavily in infrastructure that can hold open hundreds of thousands of live connections without buckling. If you've ever seen a live score app freeze or lag right when a match gets tense and traffic spikes, that's usually this exact bottleneck showing up.

For everyday use, you don't need to think about any of this — it just quietly makes apps feel responsive instead of stale. But the next time a page updates itself without you lifting a finger, you'll know there's a connection sitting open in the background, waiting to tell your browser something the moment it happens, rather than waiting to be asked.