High level design for messenger like whats app?

Question

I need to design the similar stuff like whats app or any messenger like module.

High level flow

Client > Load Balancer > Web servers(assume 10 clustered server for now) > Rest based controller > Service > DAO > DB

Challenge :-

say Friend 1 and Friend 2 are online . Friend 1 has established HTTP web connection to web server 1 and Friend 2 has established HTTP web connection to web server 2. Friend 1 send the message to Friend 2.

Now as soon as message comes to web server 1, i need to convey the message to web server 2 so that message can be pushed back to friend 2 through already established web connection

I have couple of related questions here :-

1. I can use distributed queues to propagate the message from one server to another. As soon as message comes to one server , it will push it to distributed queue(distribute queue because of load balancing and high availability) with message content, fromUserId, toUserId. My question how the right server (in this case web server 2) will be notified ? because if i use JMS queue , only one server will be notified through listener. If i use topic all servers will be notified . In this case all servers can reject the message except the one server where fromUserId resides. Is there a better way where queue just notifies the right server based on some meta data ?

Also if destinationUserId is offline, i need to put back the message on queue. Not sure how it can be achieved ? I believe we need to use some other queue implementation(probably java based in-memory queue) instead of JMS queue/topic ? Server code will only remove the message from custom queue once it gets acknowledgement from client.

2. If any client is offline at the time message is sent, in that case whe he coming online,he will send the pull request . Server will make the request to distributed queue , distributed queue will pull the message from right physical queue. My question ia should distributed queue will keep the destinationUserId and message as value in metadata ?

3. DB vs Queue :- With this approach i believe there is no need to store the message in DB which can be costly(time complexity) than queue(in-memory queue) in highly real time application like messenger. We just need to store user/group details in db.

Update :- I found related link at quora where last point i.e. What protocol is used in Whatsapp app ?... by Kah Seng Tay also confirms the simialr approach using queue , but still my above questions on queue are yet to be answered.