Experiments with Real-time Push Notifications

A major technological challenge in any on-demand business relies on server and the client app communication — on how the server sends across vital information to the relevant client on a real-time basis.

The most obvious method here is to keep polling the server every x minutes/seconds. The frequency of polling plays a key factor here — a higher frequency would hamper the server performance and/or the client app battery whereas a lower frequency might result in non-real time experience. A better way of handling these use cases is via the Push technology — where the server acts as the client and pushes request to the client app.

We first started with GCM — Google Cloud Messaging Service. However, soon after couple of weeks of pilot we realised that it cannot be a way forward for real-time services. Primary reasons being the following

• Performance Variation — The delivery performance of the payload depends upon the load in the Google Messaging Queue. While in most of the test cases we got the message received within a minute, ground performance used to vary with an average of around 2–3 minutes
• Unreliable and high heartbeat intervals — It takes longer for a broken connection to reconnect and hence, on ground (where network fluctuations often break the connection) a considerable delay in payload delivery was observed. Refer this link for more discussion
• Sandboxed tool — While it is good to have a built in tool with APIs exposed for respective functions but at the same time it is difficult to go under the hood and play with configurations.

We then moved to Pubnub. On testing its performance on ground, we observed issues in establishing reconnection when on a fluctuating network. Though we synced up with their team but with time running out of our hands we thought of switching to a different method.

The next method was more of a indigenous hack considering the Indian internet infrastructure. We took cue from the transactional SMS service that are currently used by banks for OTP verification. We used to trigger SMSs via API and then let the app read them automatically to capture the information (like the way WhatsApp auto-reads the OTP SMS). Since our app was used internally by our employees, this method worked well for all the business cases. Transactional SMS have an SLA of under 30 seconds and the good part with them is that they work independent of internet connectivity. Also, no socket connection with server is required so this solution was battery efficient as well.

Even though the business cases were solved, we still wanted to look out for a proper technical solution to the problem, on how companies like Uber, Facebook Messenger solve it. This quest landed us to a very beautiful protocol — MQTT. This is why we love this protocol

• Light weight — Its payload is roughly 4 times less than that of HTTP. As a result of this feature, it is easy to publish and subscribe to information even on low strength internet networks
• Easy to setup Infrastructure — The Eclipse Paho project provides open-source client implementations of MQTT and MQTT-SN messaging protocols. Client libraries are available for most of the popular languages, including Python, GoLang, .Net, Java and Javascript. You can download the client libraries from this link.
• Deeper Control — One can configure the expiration time, setup logic on read receipts, configure channels using wildcards etc. Mosquitto broker along with Paho libraries allow to manage the communication in a manner which works best for any given use case. (In most cases, Mosquitto broker is used in the initial setup of communication channel. It is an open source MQTT message broker.)

There are constraints in scaling which we learnt over the course of our usage. I would like to discuss them in some upcoming posts. Please reach out for any questions/clarifications.