Wt

The simple chat example and post/postAll are only for communication within the same process, so if you want horizontal scaling, you'd have to look into some other system to communicate between all of the different instances. There's all sorts of ways to do that, but that's outside of the scope of Wt.

post should have minimal overhead (most of the heavy lifting is done by Boost Asio). I can't give you an exact number as to how much memory will be required, and this is highly dependent on your application. You'll have to test your application to see.

Just as a learning exercise, I was thinking of a simple web app with blog and chat features that will be horizontally scalable. So the idea is to use citusdata postgres extension, and shard blog, account and session related tables on one node, and chat related tables on the other. And then put Wt in front of each of these two nodes. Initially I had thought of distributing all the database tables equally on both the nodes, but looking at your response, it looks like an additional message bus will be required. So instead I am thinking of using postgres as a message queue system by using listen/notify; and put all chat related tables on one node. But how difficult it will be to use Wt in front of this DB design is the question, because Wt maintains WApplication instance and session information for each app connection which will not be easy for horizontal scaling.

Is my understanding correct? And what will be a better design to use Wt so that it is horizontally scalable with a citusdata like database system?

But how difficult it will be to use Wt in front of this DB design is the question, because Wt maintains WApplication instance and session information for each app connection which will not be easy for horizontal scaling.

You'll need to make sure sessions are "sticky". Because Wt sessions are local to a particular WServer instance (and thus a specific process) you have to make sure that if a client connects to a certain backend server, it will continue to go to the same backend server. Some load balancing reverse proxies can handle this themselves with a cookie or a hash of e.g. the client's IP address. You can also handle this by setting a session id prefix (<session-id-prefix> in wt_config.xml or the --session-id-prefix wthttp argument), and configuring your reverse proxy to look at the wtd parameter and decide which backend server to send requests to accordingly. See also this blog post.