Skip to content

A simple implementation of WebSocket architecture that scales ⚡

License

Notifications You must be signed in to change notification settings

akarmanya/wscale

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

14 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

An implementation of a Scaled WebSocket Architecture

Motivation

Why are WebSockets difficult to Scale ?

In the traditional Client-Server model, the client communicates with the server via the HTTP protocol. This consists of request-response pairs. A three way handshake happens establishing a TCP connection. Post the TCP connection, HTTP request-response pairs are transmitted between the client and server.

HTTP request-response pairs

HTTP is a stateless protocol

However, this way of communication is stateless, since one client can request to multiple HTTP servers and the client state need not be stored in the server. Therefore, millions of clients can be served independently across multiple HTTP servers that are load balanced by reverse proxy servers. Therefore, HTTP servers are horizontally scalable.

NOTE

However, note that a typical HTTP server cannot, on its own, initiate a communication. It can only respond back to the incoming request initiated by a client. Hence, the server cannot broadcast or issue Server Sent Events simply because the server just does not know the state of the client.

WebSocket is a stateful protocol

However, in case of a WebSocket protocol, one client is bound to a single WebSocket server and the WebSocket server knows the state of the client. The server can broadcast or multicast events that are initiated from the server itself. This can happen simply because the way of communication is stateful and the server knows the state of the client. This helps in low latency real time communications between the client and the server. Now, a loss of connection implies the loss of state.

Note that one client ideally binds to one WebSocket server and this server maintains the state of the client. However, just simply scaling the WebSocket servers horizontally cannot replicate the states across the multiple WebSocket servers and vertically scaling a WebSocket server is capped by hardware limitations.

This #PR resolves #RP

Architecture

Load Balancing and Pub-Sub

Replicating the states across multiple WebSocket Severs

Deciding between Apache Kafka and Redis Pub-Sub

Adding a Distributed Caching Layer to cut down Network & DB calls