Structure of chat application and required technologies Structure of chat application and required technologies apache apache

Structure of chat application and required technologies


I believe your architecture is one of the best possible for such application.

I would like to state a few corrections, though.

You only need one socket with each client to monitor their online status and to transfer messages through it.

Something important you'll have to consider is security. You will certainly need an SSL certificate and encrypted communication, especially for messages. Thus you will have to consider very carefully how you are going to transfer messages and probably use an asymmetric encryption on both your servers and clients. (Note that to make you client side MITM resistant, the JavaScript that which encrypts and signs messages will have to be transferred over a secure connection - HTTPS).

The XMPP Protocol is a good idea (I give credit to @Schwertfisch), but might not be easy to implement. Fortunately there are JavaScript libraries available that implement it like Strophe.js which I guess will make things simpler.

Another thing you will have to consider is your database. While a relational model could serve well enough for such purpose it will most surely fail you if you have more traffic. I would recommend using NoSQL database engine like MongoDB or you might use the PaaS-like DynamoDB.
A well designed NoSQL storage will certainly boost your application's performance. Using DynamoDB will also discard the poor configuration and maintenance factors.

Also if you are planning to get big at some point of time you will have to make each of your application components scalable. Consider carefully all kinds of caching, storing data and etc. especially for the Node.js servers. You will have to make a backbone network to transfer messages between Node.js instances if for example two users are connected to different Node.js instances.

Client A > Chat Server 1 > Chat Server 2 > Client B

You can use protocols like MPI or a Message Queue to handle this backbone communication.

I would like to summarise that what you are planning is not that easy task. I know that there can be an easier implementation, but note that if you choose it, at some point of time not only you might have to rewrite everything, but also you might experience instability issues and that may turn down users.

Just one last piece of advice: Use the Latest and Greatest Technologies available out there and you might just do better than Facebook.

This sounds like a big system and an ambiguous project, so Good Luck and consider everything.


A more modern and much simpler to implement solution than the one I proposed in my previous answer is to use a Pub/Sub service and WebSockets. The way this works is when a client establishes a WebSocket to your app you subscribe them to a corresponding Pub/Sub channel (chat room) and then forward all messages received to the socket. When someone sends a message you publish it on the corresponding Pub/Sub channel and the service will then forward it to all subscribers.

With this architecture, development is much simpler and faster and all you need to do is to fill the gap between WebSocket and the Pub/Sub service.

In regards to scalability Pub/Sub services are easily scalable and you can simply scale your application servers horizontally to handle more traffic.

Here is a list of some software and services that supports Pub/Sub messaging: