How do you scale a viral Facebook app that has skyrocketed to a mind boggling 65 million installs (the population of France)? That’s the fortunate problem BuddyPoke co-founder Dave Westwood has and he talked about his solution at Wednesday’s Facebook Meetup. Slides for the complete talk are here. For those not quite sure what BuddyPoke is, it’s a social network application that lets users show their mood, hug, kiss, and poke their friends through on-line avatars.
In many ways BuddyPoke is the quintessentially modern web application. It thrives off the energy of social network driven ecosystems. Game play mechanics, viral loops, and creative monetization strategies are all part of if its everyday conceptualization. It mashes together different technologies, not in a dark Frankensteining sort of way, but in a smart way that gets the most bang for the buck. Part of it runs on Facebook servers (free). Part of it runs on flash in a browser (free). Part of it runs on a storage cloud (higher cost). And part of runs on a Platform as a Service environment (that’s GAE) (low cost). It also integrates tightly with other services like PayPal (a slice). Real $$$ are made selling virtual goods like gold coins redeemable in pokes. User’s can also have their avatars made into dolls, t-shirts, and a whole army of other Zazzle powered gifts.
Ivan Zuzak wrote a fascinating article on Real-time feed processing and filtering using Google App Engine to build Feed-buster, a service that inserts MediaRSS tags into feeds that don’t have them. He talks about using polling and PubSubHubBub (real-time) to process FriendFeed feeds. Ivan is trying to devise a separate filtering service where:
- filtering services should be applied as close to the publisher as possible so notifications that nobody wants don’t waste network resource.
- processing services should be applied as close to the subscriber so that the original update may be transported through the network as a single notification for as long as possible.
Besides being a generally interesting article, Ivan makes an insightful observation on the nature of using polling services in combination with metered Infrastructure/Platform services:
Polling is bad because AppEngine applications have a fixed free daily quota for consumed resources, when the number of feeds the service processed increased - the daily quota was exhausted before the end of the day because FF polls the service for each feed every 45 minutes.
This fits directly in with the ideas in
Cloud Programming Directly Feeds Cost Allocation Back into Software Design. My general preference is to poll a distributed queue for work items. It’s robust and allows your system to control it’s own resource usage by determining when to poll. Otherwise you can easily be overwhelmed by fast pushers. Here the overwhelming is going the other way. Your budget is being overwhelmed by the polling requests. And the more you try approximate real-time with frequent polling requests the more your budget is busted.
It’s a cool example of how costs, algorithm, and platform choices all feed into and shape product architectures.