Get my system design playbook for FREE on newsletter signup:
This post outlines how websockets work. You’ll find references at the bottom of this page if you want to go deeper.
Share this post & I'll send you some rewards for the referrals.
Once upon a time, there lived a student named Jonas.
Although extremely bright, he struggled with chemistry lessons.
And spent countless hours doing homework.
So he was sad and frustrated.
Until one day, he decides to ask for help with homework from his friend, Emma.
And shares a Google Document with her.
The changes have to be visible in real-time to both of them, which means a bidirectional communication pattern is necessary.
Let’s quickly look into potential communication patterns to handle this use case:
1. HTTP Request Response
The client requests the server for an update, and the server responds after processing it. Although this approach is simple and efficient, the client has to request the server again for an update. So it isn’t real-time.
2. Short Polling
Imagine polling as automatically refreshing the browser every few seconds to check a stock’s price.
The client periodically asks the server for an update, while the server returns an empty response if nothing has changed. It can track changes in real time.
Yet there are some problems with this approach:
Responsiveness depends on the interval between requests.
Extra overhead from connection requests and empty responses.
So it’s inefficient for this use case.
3. Long Polling
Think of long polling as asking a restaurant waiter for food, and then waiting at the counter until it's ready.
The client requests, and the server responds only when there’s an update.
Put simply, the server doesn’t send an empty response; instead, it holds the request and waits for an update to occur. Yet the server sends an empty response on timeout.
And client has to make an extra request to receive every change.
Although it allows real-time communication, there are some problems with this approach:
The server has to maintain many open connections, and it consumes resources.
The client has to make a separate request for sending data to the server.
So it’s inefficient for this use case.
4. Server-Sent Events
Think of SSE like a radio broadcast, it's one way and listeners can't talk back to the radio station.
The client requests the server, and it creates an open connection with the client.
The server then updates the client whenever anything changes. Yet the communication is unidirectional, and the client has to make a separate request to send data to the server.
So it's inefficient for this use case.
Ready for the best part?
Trae - Sponsored
Meet Trae, an adaptive AI IDE that transforms how you work, collaborating with you to run faster:
Simply describe your project needs in natural language, and watch it built by Trae.
Upload your design files and let Trae assist in translating your visual concepts into clean, workable code.
As you code, Trae learns your project patterns and provides contextually relevant suggestions to help you code more efficiently.
How Do Websockets Work
Google Docs use websockets for bidirectional communication in real-time.
Imagine websockets as a telephone call, both people can talk at the same time.
Here’s how it works: