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:
1. Opening a Websocket Connection
The technique of opening a websockets connection is called the handshake.
Here’s how it works:
The client sends an HTTP GET request to the server asking for a websocket connection.
The HTTP request includes specific headers.
The server returns an HTTP 101 Switching Protocols response code if it’s ready.
The handshake is complete and opens a Transmission Control Protocol (TCP) connection for bidirectional communication.
The client and server can exchange data in both directions in real-time. It supports text and binary data formats.
Onward.
2. Transferring Data Through Websockets
A websocket message can be split into frames for performance. A frame contains information such as payload data in binary syntax.
A frame allows the sender to have only a small buffer to keep data. The receiver then assembles the frames to reconstruct the original websocket message.
3. Closing a Websocket Connection
The technique of closing a websocket connection is called closing handshake.
The client or server can close the connection. A websocket frame with a specific code is used to signal the close. The connection is closed after the receiver acknowledges it.
The server then deallocates the resources.
Websocket is efficient because it can send updates through a single connection.
Yet it needs a persistent and stateful connection between the client and server. While a server can handle only a limited websocket connections because of memory and socket limitations.
Although good for specific use cases, it isn’t a silver bullet for real-time communication.
Subscribe to get simplified case studies delivered straight to your inbox:
Want to advertise in this newsletter? 📰
If your company wants to reach a tech audience, you may want to advertise with me.
Thank you for supporting this newsletter. Consider sharing this post with your friends and get rewards. Y’all are the best.
so if "Although good for specific use cases, it isn’t a silver bullet for real-time communication."
what is the silver bullet (the best solution for real time communication) ?
If google docs uses websockets - how does google docs handle the server limited websocket connections issue?
Interesting Read!