Picking right messaging broker

I had implemented my last company (Plustxt) product over eJabbered. It worked well for couple of hundred thousand users but after I sold the company to Paytm and implemented for over 50+ million users, we immediately started noticing bottlenecks with scaling XMPP but also more importantly started facing heavy battery drainage in mobile. One of the most critical infrastructure for Glowing is also messaging broker. Inspite of great deal of knowledge sunk-in cost in eJabbered, we took the challenge of exploring for much better and reliable technologies.

Following were salient points we considered before picking the right solution:

  1. Ease of portability to platforms like having socket extension for web and MQTT for mobiles
  2. Lightweight
  3. Enterprise level message delivery, which would mean
    1. swift response
    2. for both device and web
    3. low latency
    4. no loss of message
    5. availability
    6. scalability
    7. eventual consistency

Its also interesting with the advent of mobiles, how presence is dying hence we also needed to work on presence from scratch as presence implementation of eJabbered is again very battery hogging.

RabbitMQ turned out to be a very interesting candidate with support for AMQP, MQTT and STOMP protocol. We also evaluated mosquito server but realised is not mature enough yet for multiple platforms (and protocols). For web, we decided to have a layer over that taking care of authentication. Having a layer also helps in taking care of not exposing queue or topic names which is also very important as fronted can be broker terminology independent and will help us scale component wise in a service oriented architecture.

Will post more on the challenges we faced and how we took care of those in coming posts. Please do contact us for any suggestions or recommendations.

Leave a Reply

Your email address will not be published. Required fields are marked *