A fresh look at push vs. pull in mobile design
Shawn Tooley 270006VAPH firstname.lastname@example.org | | Tags:  pull patterns websphere push mobile application server design
0 Comments | 1,283 Visits
Author Hugh Lofting's "Doctor Dolittle" featured an intriguing two-headed animal character called a pushmi-pullyu. Upon starting to move, its heads would go in opposite directions until both minds, equally stubborn, agreed on a common direction.
The same push-pull battle has been waged in the world of mobile application design since mobile devices were invented. Should users submit queries to pull the latest information from the systems of record? Or should the most critical information be pushed to users' devices proactively?
Naturally, there is no one-approach-fits-all answer. But two forward thinkers at IBM have come up with a model that shows that in the proper situations, a push design could consume just a small fraction of the network, server, and other resources needed to support the same application in a traditional pull-based architecture.
I just finished editing Mobile Design Patterns: Push, Don't Pull, an IBM Redbooks Point-of-View by IBM WebSphere VP Jerry Cuomo and Program Director Robert Vila. And it's an eye opener. The authors use a mobile banking scenario to show the dramatic resource savings that could be achieved by using push notifications to update users' mobile banking apps. They say their approach might even lead to the elimination of banking apps' “Check Balance” buttons, which millions of users press several times each day, initiating multiple millions of resource-intensive queries to bank servers.
How much more efficient might a push pattern be in these instances?
By the authors' reckoning, for common bank account-related queries, a typical pull pattern results in 20 million so-called load units on a bank's back-end systems each day. That's in part because users frequently press "Check Balance" even when there has been no change to their account.
By changing to a push design, a messaging infrastructure would bypass the bank's web servers and send secure updates to each user's device whenever (and only when) the user's account balance has actually changed. The back-end server load would be trimmed to just 4 million load units a day -- an 80% savings compared to the pull approach. Eventually, when users come to trust that their app's balance information is always current, there would even be less need for the bank to maintain the higher server capacity that is required today to handle the deluge of "Check Balance" requests that come in on paydays. At these peak query times, the authors see app-related server load dropping to as little as 1/25 of what is today.
Like I said, the piece is an eye opener. It has convinced me that banks and other enterprises will be heading in the direction of push patterns in future mobile applications. I think even a pushmi-pullyu would agree that is where things are heading.