Messaging Architecture in < 2 min

The essence of your favorite messaging applications.

Messaging Server

The most important thing to understand is that a client cannot simply send a message to a server and the server sends to another client. Server initiated requests are not supported via HTTP.

Instead a web socket will need to be utilized.

But hold on a second. Lets say I have a million clients using this messaging service. Am I really gonna have to support a million socket connections on a single server.

Ofc not. I would recommend having a kubernetes cluster with a load balancer. Clients establish connection with different servers in the cluster. A table or cache is kept that shows which server each client is connected to. If A wants to send a message to B, A’s server, simply looks up server for B and sends the message there. Then B’s server pushes the message to B’s client via web socket. The message should also be persisted in a db

If B is not currently connected, no problem, simply have A’s server persists the message in db and when B establishes connection again it can just pull from db.

To dive one level deeper, within each server, a new thread or process will be spawned to handle requests for a particular client, there will also likely be a queue of messages specific to each client (queue that holds messages from other clients)so that the thread can process them and send them away.

Image Server

Okay sending images and videos over web socket is a bit much. (Lags and stuff like that). Instead use a CDN. When A sends an image to B, instead of going through normal messaging server. The image will be uploaded to CDN. A hash of the image will be sent to B, and B can use that hash to download the image from CDN. There everyone is happy