How WebSockets work, its tradeoffs, and how you can design an actual time messaging app
Actual-time communication is in every single place — reside chatbots, knowledge streams, or prompt messaging. WebSockets are a robust enabler of this, however when must you use them? How do they work, and the way do they differ from conventional HTTP requests?
This text was impressed by a current system design interview — “design an actual time messaging app” — the place I stumbled by way of some ideas. Now that I’ve dug deeper, I’d wish to share what I’ve discovered so you’ll be able to keep away from the identical errors.
On this article, we’ll discover how WebSockets match into the larger image of shopper‑server communication. We’ll focus on what they do effectively, the place they fall quick, and — sure — how you can design an actual‑time messaging app.
At its core, client-server communication is the alternate of information between two entities: a shopper and a server.
The shopper requests for knowledge, and the server processes these requests and returns a response. These roles usually are not unique — companies can act as each a shopper and a server concurrently, relying on the context.
Earlier than diving into the small print of WebSockets, let’s take a step again and discover the larger image of client-server communication strategies.
1. Brief polling
Brief polling is the best, most acquainted strategy.
The shopper repeatedly sends HTTP requests to the server at common intervals (e.g., each few seconds) to verify for brand spanking new knowledge. Every request is unbiased and one-directional (shopper → server).
This methodology is simple to arrange however can waste sources if the server hardly ever has recent knowledge. Use it for much less time‑delicate purposes the place occasional polling is enough.
2. Lengthy polling
Lengthy polling is an enchancment over quick polling, designed to cut back the variety of pointless requests. As a substitute of the server instantly responding to a shopper request, the server retains the connection open till new knowledge is offered. As soon as the server has knowledge, it sends the response, and the shopper instantly establishes a brand new connection.
Lengthy polling can also be stateless and one-directional (shopper → server).
A typical instance is a trip‑hailing app, the place the shopper waits for a match or reserving replace.
3. Webhooks
Webhooks flip the script by making the server the initiator. The server sends HTTP POST requests to a client-defined endpoint every time particular occasions happen.
Every request is unbiased and doesn’t depend on a persistent connection. Webhooks are additionally one-directional (server to shopper).
Webhooks are broadly used for asynchronous notifications, particularly when integrating with third-party companies. For instance, fee programs use webhooks to inform purchasers when the standing of a transaction adjustments.
4. Server-Despatched Occasions (SSE)
SSEs are a native HTTP-based occasion streaming protocol that permits servers to push real-time updates to purchasers over a single, persistent connection.
SSE works utilizing the EventSource API, making it easy to implement in trendy internet purposes. It’s one-directional (server to shopper) and superb for conditions the place the shopper solely must obtain updates.
SSE is well-suited for purposes like buying and selling platforms or reside sports activities updates, the place the server pushes knowledge like inventory costs or scores in actual time. The shopper doesn’t have to ship knowledge again to the server in these eventualities.
However what about two-way communication?
All of the strategies above deal with one‑directional movement. For true two‑method, actual‑time exchanges, we want a distinct strategy. That’s the place WebSockets shine.
Let’s dive in.
WebSockets allow real-time, bidirectional communication, making them excellent for purposes like chat apps, reside notifications, and on-line gaming. Not like the normal HTTP request-response mannequin, WebSockets create a persistent connection, the place each shopper and server can ship messages independently with out ready for a request.
The connection begins as an everyday HTTP request and is upgraded to a WebSocket connection by way of a handshake.
As soon as established, it makes use of a single TCP connection, working on the identical ports as HTTP (80 and 443). Messages despatched over WebSockets are small and light-weight, making them environment friendly for low-latency, high-interactivity use instances.
WebSocket connections observe a selected URI format: ws:// for normal connections and wss:// for safe, encrypted connections.
What’s a handshake?
A handshake is the method of initialising a connection between two programs. For WebSockets, it begins with an HTTP GET request from the shopper, asking for a protocol improve. This ensures compatibility with HTTP infrastructure earlier than transitioning to a persistent WebSocket connection.
- Consumer sends a request, with headers that seem like:
GET /chat HTTP/1.1
Host: server.instance.com
Improve: websocket
Connection: Improve
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://instance.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Model: 13
Improve— alerts the request to modify the protocolSec-WebSocket-Key— Randomly generated, base64 encoded string used for handshake verificationSec-WebSocket-Protocol(non-compulsory) — Lists subprotocols the shopper helps, permitting the server to select one.
2. Server responds to resquest
If the server helps WebSockets and agrees to the improve, it responds with a 101 Switching Protocols standing. Instance headers:
HTTP/1.1 101 Switching Protocols
Improve: websocket
Connection: Improve
Sec-WebSocket-Settle for: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Settle for— Base64 encoded hash of the shopper’sSec-WebSocket-Keyand a GUID. This ensures the handshake is safe and legitimate.
3. Handshake validation
With the 101 Switching Protocols response, the WebSocket connection is efficiently established and each shopper and server can begin exchanging messages in actual time.
This connection will stay open until it’s explicitly closed by both celebration.
If any code aside from 101 is returned, the shopper has to finish the connection and the WebSocket handshake will fail.
Right here’s a abstract.
We’ve talked about how WebSockets allow real-time, bidirectional communication, however that’s nonetheless fairly summary time period. Let’s nail down some actual examples.
WebSockets are broadly utilized in real-time collaboration instruments and chat purposes, akin to Excalidraw, Telegram, WhatsApp, Google Docs, Google Maps and the reside chat part throughout a YouTube or TikTok reside stream.
1. Having a fallback technique if connections are terminated
WebSockets don’t mechanically recuperate if the connection is terminated as a consequence of community points, server crashes, or different failures. The shopper should explicitly detect the disconnection and try to re-establish the connection.
Lengthy polling is commonly used as a backup whereas a WebSocket connection tries to get reestablished.
2. Not optimised for streaming audio and video knowledge
WebSocket messages are designed for sending small, structured messages. To stream massive media knowledge, a expertise like WebRTC is healthier suited to these eventualities.
3. WebSockets are stateful, therefore horizontally scaling shouldn’t be trivial
WebSockets are stateful, that means the server should keep an lively connection for each shopper. This makes horizontal scaling extra advanced in comparison with stateless HTTP, the place any server can deal with a shopper request with out sustaining persistent state.
You’ll want a further layer of pub/sub mechanisms to do that.
Now let’s see how that is utilized in system design. I’ve coated each the easy (unscalable) resolution and a horizontally scaled one.