Related: Database Design Best Practices for Web Apps
Some apps need to feel alive. A chat message should appear the instant it is sent. A live score, a stock price, or a delivery map should update on its own, with no refresh. WebSockets are the technology that makes this possible. They keep an open, two way line between the browser and the server, so either side can send data the moment it has something to say. This guide explains what WebSockets are in plain words, how they beat older methods like polling, where they fit, and how to scale them without pain.
Key takeaways
- A WebSocket is a persistent, two way connection between browser and server, so both sides can send data at any time.
- Normal HTTP is one way and one shot: the client asks, the server answers, the connection closes.
- Polling fakes real time by asking again and again. It wastes requests and still feels laggy. WebSockets remove that waste.
- Good uses are chat, live dashboards, notifications, collaborative editing, and multiplayer games.
- Scaling WebSockets is different from scaling HTTP, because connections stay open. A message broker like Redis usually solves it.
What a WebSocket is
To see what makes WebSockets special, first picture normal web traffic. A standard HTTP request is like sending a letter. The browser asks for a page, the server sends it back, and the exchange is over. If you want new data, you send another letter. The server cannot start the conversation. It can only reply when asked.
A WebSocket is more like a phone call that stays connected. The browser and server shake hands once, over a normal HTTP request that then upgrades to the WebSocket protocol. After that the line stays open, and either side can speak at any time without asking first. The server can push a new chat message the instant it arrives. That open, two way line is the whole point.
WebSockets versus polling
Before WebSockets were common, developers faked real time with polling. It is worth understanding, because it explains what WebSockets fix.
Short polling means the browser asks the server every few seconds, are there any updates? Most of the time the answer is no, so you send a flood of requests for nothing, add load to the server, and updates still arrive late. Long polling is smarter: the server holds the request open until it has news, then answers. It feels closer to real time but is still heavy, since each update needs a fresh request and response cycle.
WebSockets replace all of that with a single open connection. Here is the comparison.
| Method | How it works | Downside |
|---|---|---|
| Short polling | Client asks on a timer | Wasted requests, laggy, high load |
| Long polling | Server holds the request until it has news | Better, but still one request per update |
| WebSocket | One open two way connection | Different scaling model to plan for |
There is also a lighter option worth knowing. Server-sent events, or SSE, give you a one way stream from server to browser over plain HTTP. If you only need the server to push updates and never need the browser to reply on the same channel, SSE is simpler. For a live price ticker or a notifications feed, it is often enough. Reach for a WebSocket when you truly need two way, low latency traffic.
Where WebSockets fit
WebSockets shine whenever data changes often and users expect to see it right away, or when many users interact live. Common cases include:
- Chat and messaging. The classic use. Messages appear the moment they are sent, and you can show typing indicators and read receipts.
- Live dashboards. Metrics, logs, and monitoring screens that update themselves as numbers change.
- Notifications. Alerts that pop up the instant something happens, with no refresh.
- Collaborative editing. Documents, whiteboards, and design tools where several people edit at once and see each other move.
- Live tracking. A delivery map or a ride location that moves across the screen in real time.
- Multiplayer games. Fast, back and forth updates between players and the server.
Not every app needs this. If your data changes rarely, or a short delay is fine, plain HTTP is simpler and cheaper. Add a persistent connection when the experience truly needs to feel live, not because it sounds modern. Many teams use a library like Socket.IO to smooth over browser quirks and add automatic reconnection and rooms, though the raw WebSocket API works well too.
How WebSockets change scaling
This is the part teams underestimate. Scaling WebSockets is not the same as scaling normal web traffic. Normal HTTP requests are short, so one server can handle a huge number of them and move on. WebSockets stay open. Every connected user holds a live connection for as long as they are on the page, and a server can only hold so many open connections at once, so you run out of room in a new way.
The second challenge is talking across servers. Say you run three servers behind a load balancer. User A is connected to server 1 and sends a chat message. User B, who should receive it, is connected to server 2. Server 1 has no direct way to reach a connection it does not hold, so the message is stuck on the wrong server.
Scaling WebSockets simply
The good news is that this is a solved problem, and the solution is not complicated. The common pattern uses a message broker in the middle, most often Redis, with its publish and subscribe feature.
It works like this. Every server subscribes to the broker. When a server receives a message from one of its users, it does not try to deliver it alone. It publishes the message to the broker. The broker then hands it to every server. Each server checks which of its own connected users should get it, and pushes it down those open connections. Now it does not matter which server a user is connected to. The message reaches them.
| Step | What happens |
|---|---|
| 1 | User A sends a message to server 1 |
| 2 | Server 1 publishes it to the Redis broker |
| 3 | The broker delivers it to all servers |
| 4 | Each server pushes it to its own matching users |
A few more practical points make real deployments smoother. Use a load balancer that supports WebSockets and, where needed, sticky sessions so a user stays on the same server for the life of the connection. Plan for reconnection, because phones change networks and connections drop. Most client libraries reconnect on their own, but your app should handle a brief gap and catch up on any missed messages. If your product serves many separate customers, keep this in mind alongside the wider concerns in our guide on how to secure a web application, since an open connection still needs authentication and rate limits.
FAQ
What is the difference between WebSockets and HTTP?
HTTP is one way and short lived. The client sends a request, the server sends a response, and the connection closes. The server cannot start a message. A WebSocket opens a persistent two way connection after an initial HTTP handshake, so both the client and the server can send data at any time. That is why WebSockets suit live features and plain HTTP suits normal page loads.
Do I always need WebSockets for real-time features?
No. If you only need the server to push updates one way, server-sent events over HTTP are simpler and often enough, for example a price ticker or a notifications feed. Polling can also work when a short delay is acceptable. Choose a WebSocket when you need true two way, low latency traffic, such as chat, collaborative editing, or a multiplayer game.
How do you scale WebSockets across many servers?
Use a message broker, most commonly Redis with publish and subscribe. Each server subscribes to the broker. When one server gets a message, it publishes it to the broker, which delivers it to all servers, and each one pushes it to its own connected users. You also want a load balancer that supports WebSockets and a plan for clients to reconnect after a dropped connection.
Working with Apex Logic
We build real-time features that stay fast and reliable as they grow, from live chat and dashboards to collaborative tools, with scaling and reconnection handled properly. See our services or contact us to talk through the live experience you have in mind.
References
MDN Web Docs, the WebSocket API and server-sent events.
Redis documentation, publish and subscribe messaging.
Apex Logic project experience building and scaling real-time applications.
Comments