A messaging aggregation platform is a platform that is capable of receiving and sending messages to multiple (and popular) messaging platforms. Existing messaging apps installed on user devices act as invisible apps available for and tie into our platform. Benefits for end (consumer) users who consistently rely and use a favorite platform include not needing to install any new apps, let alone change and learn new behavior; but rather, businesses that use a messaging aggregation platform merge into current habits and preferences of users.
We evaluated using just SMS to empower our invisible app ecosystem, but soon realized it is limiting as many users now prefer using data-based apps. Also, WiFi connectivity can be more prevalent and reliable in many locations (ex: hotels) as compared to cellular networks. For international guests, SMS turns out to be very expensive. A messaging aggregation platform is the *only* answer for building a global and reliable guest communication system. Add AI on the top of it, and we invite you to the new world of Invisible Apps.
Messaging aggregation is brave new world which has not been successfully implemented anywhere yet. Most important challenges involved in building such a platform as we have observed are below (we believe challenges are mainly dealing with unknowns – for knowns, its just a matter of thinking and doing in a right way):
1: Reverse Engineering
Every messaging platform comes with their own proprietary communication interface. We need to reverse engineer functionality of apps and build our own system. This is not as simple as it sounds. Keep reading. If we are really lucky, we will get APIs but never enterprise grade ones as focus of these messaging companies is consumer first. It takes days to get issue resolved or get knowledge transferred. Also, reverse engineering is not just figuring out APIs to send and receive messages, it’s just a small part of it. Since messaging platforms involve a live connection, other things such as maintaining pings, replying to receipts, acknowledging status changes, etc. become very important; otherwise, the messaging platform will just break the connection resulting in messages unable to be received.
2: Made for humans, not machines
Messaging platforms are built to avoid hacks and bots attacking their system. This means that systems which will be built to talk to these messaging platforms should act like humans. For instance, it would be impossible for a human to send 5 messages in 1 second over Whatsapp. The system architecture needs to take care of all such human factors. We don’t just guess, we experiment with all these factors. In initial days of development, there were times when all of our test phone numbers were blocked by Whatsapp for 45 days. This is common still for us, as we keep on rigorously testing various use cases at the risk of test phones being banned. In fact, I would say testing to resolution has taken much more time than our complete development time, and I would not be surprised that it will take more 2-3x the overall maintenance effort. But once it is out, developed and stable, it is definitely worth the time invested.
3: Unannounced platform changes
Messaging platforms will change their interface without any prior notifications and this will cause complete messaging or connection drops. It takes a substantial amount of time to understand in what circumstances such things occur. And most importantly, its very important to build infrastructure for dealing with unannounced platform changes, which will mean 24×7 availability in terms of resources. We internally also try to take care of such changes algorithmically, e.g. a simple reconnection after sometime portraying as older version of an installed app. We realized, generally, such changes gets released in a version prior to the current version in an AppStore with servers having backward compatibility. We will downgrade in this case to a version or two down, or until reconnection works. It helps us to keep the system live, to raise issue alerts and to provide the opportunity to resolve according to the latest release.
In the end, aggregation infrastructure is just not about scale, messaging brokerage, message gateways (all which have or will be discussed in more detail in other posts), but it’s more about integration durability which ensures addressing issues such as ones mentioned above. Will be extremely happy to answer any doubts, and delighted for all the recommendations.