How does messaging work in WhatsApp?

Rick Reed here talks about some of the things his team did to do to scale their application -  http://www.erlang-factory.com/conference/SFBay2012/speakers/RickReed. The rest of the answer is my guess on what a naive version of WhatsApp could do to implement it's features. WhatsApp or most of the other messaging apps rarely work on a peer to peer basis. So it wouldn't open a connection (from your device) to each of your friends' devices. Instead your device connects to their server. It could then use a custom TCP protocol or maybe HTTP to communicate your messages to the server. The server in return would dispatch them to your friends' devices. If your friend had their app open or at least the app process running there might be a live connection to the server. WhatsApp will use that connection to send them your messages. If their app is "offline" then they might choose to send them a push notification instead. WhatsApp has chosen Erlang a language built for writing scalable applications that are designed to withstand errors. Erlang uses an abstraction called the Actor model for it's concurrency - http://en.wikipedia.org/wiki/Actor_model. Instead of the more traditional shared memory approach, actors communicate by sending each other messages. Actors unlike threads are designed to be lightweight. Actors could be on the same machine or on different machines and the message passing abstractions works for both. A simple implementation of WhatsApp could be: Each user/device is represented as an actor. This actor is responsible for handling the inbox of the user, how it gets serialized to disk, the messages that the user sends and the messages that the user receives. Let's assume that Alice and Bob are friends on WhatsApp. So there is an an Alice actor and a Bob actor. Let's trace a series of messages flowing back and forth: Alice decides to message Bob. Alice's phone establishes a connection to the WhatsApp server and it is established that this connection is definitely from Alice's phone. Alice now sends via TCP the following message: "For Bob: A giant monster is attacking the Golden Gate Bridge". One of the WhatsApp front end server deserializes this message and delivers this message to the actor called Alice. Alice the actor decides to serialize this and store it in a file called "Alice's Sent Messages", stored on a replicated file system to prevent data loss due to unpredictable monster rampage. Alice the actor then decides to forward this message to Bob the actor by passing it a message "Msg1 from Alice: A giant monster is attacking the Golden Gate Bridge". Alice the actor can retry with exponential back-off till Bob the actor acknowledges receiving the message. Bob the actor eventually receives the message from (2) and decides to store this message in a file called "Bob's Inbox". Once it has stored this message durably Bob the actor will acknowledge receiving the message by sending Alice the actor a message of it's own saying "I received Msg1". Alice the actor can now stop it's retry efforts. Bob the actor then checks to see if Bob's phone has an active connection to the server. It does and so Bob the actor streams this message to the device via TCP. Bob sees this message and replies with  "For Alice: Let's create giant robots to fight them". This is now received by Bob the actor as outlined in Step 1. Bob the actor then repeats Step 2 and 3 to make sure Alice eventually receives the idea that will save mankind. WhatsApp actually uses the XMPP protocol instead of the vastly superior protocol that I outlined above, but you get the point. For your own application things to consider: You might not have control over clients sending GPS coordinates to the server every 10 minutes. If your client is running on a mobile device, the OS might decide to starve you from resources or just kill your process. You need to maintain state for clients that are connected to your server to make sure you can send messages to active clients when your requirements are met. This is a slight modification of the stock "Comet app" example that almost every framework has. Establishing a TCP connection is not a very big waste of resources either from the client's side or from the server's side. If your server software ecosystem supports non blocking IO, the state required per connection is tiny. You could support upwards of 100k connections on a mediocre box if you tried hard. If you are on the JVM Netty might help you here. Python has Twisted and Tornado. C++/ C can make use of epoll, kqueue or select if you are on a *NIX system. Golang supports a high number of connections through it's standard library. We have addressed vertical scalability here i.e. how many users could you support on a simple box. If you really want to scale out and build a distributed system that maintains state, you might want to consider Erlang (with OTP) or other implementations of the Actor model, like Akka (JVM) which also supports remote messages. A combination of event sourcing and a message passing architecture could get you all horizontal scalability you need.

From a quick search on the internet it looks like Whatsapp uses a custom XMPP server built on Erlang to handle the messaging backend. The advantage of using XMPP is it comes with built in support for rosters and presence so you don't have to manually setup infrastructure and code to manage subscriptions. Like one-to-one communication XMPP also provides you support for multi user chat which more or less just relays the messages to all users in a given chatroom. Here is a tutorial on how to do that with Ruby but it should give you a good idea of the underlying principle http://siddharth-ravichandran.com/2011/01/21/multiuser-chat-using-xmpp-and-orbited-using-ruby-on-rails/. In my opinion REST based server consuming messages with a long-polling server or Websockets should help you fetch the data from the backend. I would recommend looking into StropheJS  http://strophe.im/strophejs/ or Orbited https://github.com/gameclosure/orbited2. Orbited allows for a socket like interface with javascript and works on top of Twisted. Though I'm not familiar with the Java ecosystem I've found that the Play Framework and Lift for Scala come with built in support for long polling. However lately, I've grown partial to messaging middleware which happens to give me more flexibility to achieve the same the features. Though this means that you would have to manage the presence and rosters list yourself. I would recommend looking into Kafka or Rabbitmq. Even Redis comes with a fairly scalable pubsub feature which would help you build message queues (as Redis Lists) and publish subscribe features. REST based APIs make it easy to work with HTTP requests so every message would be "POSTed" to the server and handed to the your messaging layer or your XMPP server if your working with Ejabberd or Openfire. The message if fetched by periodically polling with a (GET) long connection timeout - which basically waits till some data arrives on the backend to make it look realtime. Websockets on the other hand would make it more event based. REST simply defines a set of rules to access the resource behind it. JSON is just another way to exchange data over the web much like XML. SOAP is another means of exchanging data using predefined XML schemas which help standardise the format in which messages are exchanged. With Whatsapp there aren't 10 different socket connections (to the best of my knowledge) but periodic long polls which wait for new data to arrive. From your requirement I feel Kafka or Rabbitmq or Redis would be better suited to implement it. The RabbitMQ site has beautifully documented the features available and would be a great place to start.

I don't know how exactly WhatsApp works but messaging described by you looks like an example of JMS. Producer(sender) can create a message which is saved in a queue. When the consumer(receiver) is available he will receive message by checking for messages or through listeners. In JMS, Sender and receiver do not have to be available simultaneously. Android sdk has google cloud messaging (GCM) through which you can send messages, please check if it can be used with iPhone/BB/Windows phone or else your app would be restricted to android only. For JMS, You can checkout example of activemq online which is an open source implementation of JMS API. Here is one such tutorial http://www.javablogging.com/simple-guide-to-java-message-service-jms-using-activemq/

Look into Message Queues - any massive communication system has to rely on them or else it simply wouldn't work. RESTful is a sensible framework for using HTTP to facilitate server/client communication and JSON is a lightweight encoding for data. Not entirely sure about SOAP, but I do know it's more heavyweight (and possibly somewhat outdated) and therefore less frequently used in web applications. All of these protocols and formats you've referenced exist because the web requires standardization: if everyone devised their own formats and protocols, communication between services would be impossible.

WhatsApp uses XMPP (eXtensible Messaging and Presence Protocol) to handle the message delivery system. XMPP is mostly like HTTP where the client opens the socket with the XMPP server and keeps it open as long as the client is logged in. It's not like the regular REST API where the client opens the socket send/receive the data and close the socket. The socket is opened as long as you are signed in. In case of WhatsApp that's eternity (not really, WhatsApp reconnects automatically if the connection terminates) XMPP protocol has been used in various chat applications such as Google Talk, Facebook messenger etc. I have been working on XMPP since last year and that's when I got to know what this protocol could bring. It's not limited to chat apps though. We're developing an application of our own which is not a chat app. As far as actual technology goes, WhatsApp uses heavily customized version of Smack library on Android to build their client and uses customized eJabberd Server to handle the XMPP traffic. They might have different backend solution for handling the data though which might be on one of the cloud storage/computing network (I think it's heroku, no real idea though). On iOS and other platforms, I suppose they might have developed their own libraries. Developing own libraries is not a lot of work, especially when you have customized needs and have a team of developers. I have used one of the libraries available for Windows Phone and heavily customized them to work for us. I made some improvement on the library, but due to time shortage I couldn't submit them to the original repo (Documentation is really tough). Anyways, if you are interested in learning the tech, you can read Oriely's "XMPP: The Definitive Guide" and can visit http://xmpp.org. Peace!

If you want to know about Whatsapp's business model / how it gets money, you can refer below links : http://www.edupristine.com/blog/cfa-alternative-investment-whatsapp-revenue-model-speculated/ https://www.idtech.com/blog/why-is-whatsapp-worth-19b-how-do-apps-even-make-money/ http://blogs.wsj.com/digits/2014/03/03/how-messaging-apps-make-money/ http://engineeringfukrey.com/how-does-whatsapp-earn-money/ http://money.stackexchange.com/questions/35336/how-do-companies-like-whatsapp-and-hike-earn-money http://www.crazyengineers.com/threads/how-do-free-apps-wechat-line-whatsapp-make-money.68970/ http://money.cnn.com/2014/02/20/technology/social/whatsapp-19-billion/ http://www.kgbanswers.co.uk/how-does-whatsapp-make-its-money-and-how-much-has-it-made-and-how-much-is-it-worth/16655509 Regarding it's technology stack, networking and how does it scale : http://highscalability.com/blog/2014/3/31/how-whatsapp-grew-to-nearly-500-million-users-11000-cores-an.html http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf See interviews and presentations by Rick Reed. These links cover the whatsapp architecture : http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html http://blog-bhaskaruni.blogspot.in/2014/02/whatsapp-architecture.html http://mirkobonadei.com/interview-with-rick-reed/ http://www.pixelstech.net/article/1371369804-Use-of-Erlang-in-WhatsApp https://blog.process-one.net/whatsapp-facebook-erlang-and-realtime-messaging-it-all-started-with-ejabberd/ Thanks.

WhatsApp is a real-time messaging application, which makes use of Ejabberd (XMPP) server. This server facilitates instant message transfer between two or many users at any given second. Eabberd is an open source Jabber server written in Erlang language. Batabase management Mnesia DB comes into play.For storing multimedia files, the app uses an exclusive web server YAWS. FreeBSD is the operating system upon which WhatsApp is laid upon. You can get full details about whatsapp architecture , go here : http://blog.contus.com/how-whatsapp-works-technically-and-how-to-build-an-app-similar-to-it/

Here i attached image for instant messaging technology works. What are functionality of server, database, protocol using Line, whatsapp, viber etc.. For more detailed information about whatsapp works: http://blog.contus.com/how-whatsapp-works-technically-and-how-to-build-an-app-similar-to-it/

The basic protocol used behind any chat application is XMPP which was initially called JABBER. Till few years back gchat also used XMPP. What is XMPP ? XMPP stands for eXtensive Messaging and Presence Protocol Data is sent to and fro to the server in small XML packets called stanza. Depending upon the requirements of the application XMPP is modified. Whatsapp uses modified version of XMPP.