Who likes queues anyway? Service agents do.
Notifications can experience variable delays on their way to mobile devices, no matter the notification or mobile app. Sometimes notifications can seem to arrive fast and sometimes they can seem to arrive slow.
This is largely due to five key factors: 1) a notification queuing model, 2) the number of hops a notification takes along its journey, 3) the setup of the network connection in between those hops, 4) the capacity of the underlying technology infrastructure along the route, and 5) the performance and settings of the mobile device. In this post, we’ll explore the first factor, notification queuing model.
Notifications are placed into a queue and processed one after the other until the queue is empty (i.e. until all notifications have been dispatched to their destination). As with any queuing model, there are inherent delays in servicing the queues depending on the number of service agents available and the efficiency of each one. The optimal number of service agents is influenced by downstream processes. Too many services agents could send too many notifications downstream too fast and overload downstream processes causing them to shut down.
This queuing model is a key reason people can receive notifications at different times despite possibly being right next to one another. It depends on where the notification targeted for their device was in the queue. If in the beginning, they will get their notification before the other person who’s notification may have been at the end of the queue.
