We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
6 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Messaging Event Systems
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Messaging Event Systems
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Every communication pattern we have covered so far has a fundamental limitation: the client initiates every exchange. Polling asks "anything new?" over and over. Long polling asks and waits. Server-Sent Events let the server push data, but only in one direction. None of them give you a true two-way conversation.
Think about a phone call. Once the call connects, either side can talk at any time. There is no "your turn" protocol. No need to hang up and redial every time you want to say something. The line stays open, and both parties communicate freely.
WebSockets are the phone call of the web. They start as a regular HTTP request, upgrade to a persistent connection, and then both client and server can send messages to each other at any time. No request needed. No overhead. No waiting.
This is how Slack delivers messages the instant someone types them. How Figma shows your collaborator's cursor moving in real time. How online multiplayer games synchronize player positions across the globe at 60 frames per second. How Binance streams over 1 million price updates per second to traders without the browser breaking a sweat.
The difference between polling and WebSockets is not incremental, it is architectural. Polling is checking your mailbox every five minutes. WebSockets is having a direct telephone line to the sender.
WebSockets do not use a new protocol from scratch. They piggyback on to establish the connection, then upgrade to the WebSocket protocol. This is clever because it means WebSocket connections work through existing HTTP infrastructure (load balancers, proxies, firewalls) without special configuration in most cases.
Step 1: The HTTP Upgrade Request
The client sends a regular HTTP GET request with special headers:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
The Upgrade: websocket header says: "I don't want regular HTTP. Let's switch to ."
The Sec-WebSocket-Key is a random base64 value used to verify the server actually understands WebSocket and is not just blindly proxying the request.
Step 2: The Server Accepts
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
The 101 Switching Protocols response means the HTTP connection is now a WebSocket connection. From this point forward, both sides communicate using WebSocket frames, not HTTP requests and responses.
Step 3: Bidirectional Communication
Now either side can send a message at any time. There are no request/response pairs. There are no headers on each message. Just raw frames flowing in both directions over a single connection.