Facebook Cookbook

Build Now, Scale Later: Getting Real

Problem

I’ve heard so many horror stories about developers who didn’t think through their scaling issues at the beginning and ended up with 250,000 users and were madly running around trying to scale their app. I don’t want to do that! I want to build in scaling right from the start. Isn’t that a smarter approach?

Solution

Go watch this video: http://youtube.com/watch?v=ntfEKmIg_VQ.

(If that video isn’t available, close your eyes and picture the iLike team madly driving around the Bay Area in a rental truck, begging, borrowing, and buying 150 rack-mounted servers and installing them in their data center, all in 48 hours.)

At the time when the iLike crew went on their mad dash, they already had six million users. The moral of this story is that you can always scale by throwing more money at servers later. It is important for you to take some time to think about scalability now, but if you plan to build out a carefully load-balanced, n-tier architecture for your zero users, you’re going to spend the next six months figuring out how to do that while someone else just does it (to quote Nike) and has a six-month head start.

Discussion

Here’s a fun exercise to get you into the right headspace. Start by drawing a line across this page, which would be defacing this book if I didn’t do it for you (Figure 4-3).

Figure 4-3. A plain old line

Now take that plain old line and transmogrify it into a fancy, educated line by adding a sophisticated label full of $5 words (Figure 4-4).

Figure 4-4. Fancy, educated-type line

Now let’s add some points of reference to that line (Figure 4-5), and then I’ll tell you a little cautionary tale.

Figure 4-5. You, bracketed by Twitters

Once upon a time, Ev Williams and his cofounders built up Pyra Labs, created the Blogger platform, and sold it to Google. The web community looked upon this and said that it was good! Then Ev started a new company called Odeo and started to build it up, and the web community looked upon it and said that it seemed fairly interesting but that they were not, as of yet, entirely convinced. One day, whilst hard at work on Odeo, a member of their stalwart team named Jack Dorsey presented an idea that had been rattling around in his head for six years. The assembled other members looked upon this idea and decided it had real merit and so, on a lark, they cobbled together a working version and released it upon the world. And so it went that in October 2006, the world discovered the newly named twttr, 140 characters at a time.

Fast forward to May 2008. With over 1.7 million users sending more than three million tweets per day on the newly renamed Twitter, now owned by the newly minted Twitter, Inc., some serious scalability problems became apparent. In an interview with Robert Scoble,^[7] taped on May 31, 2008, Ev notes (about 7 minutes and 35 seconds in) that their problem isn’t money, Ruby on Rails, or servers, but is entirely architectural. When they built twttr, they had no idea that it would become popular or that it would even spread beyond the prototype built by Jack and Biz Stone. They had no scalability plan because they didn’t think they would need one, and they followed the predominant Ruby on Rails mentality that dictates building software over spending time planning.

Ev mentions in the video that it’s not usually worth considering scalability since most products never reach a point where it’s needed, and he’s mostly right. Looking back over the first year of Facebook Platform highlights a number of apps that skyrocketed into the Top 10 almost overnight, which is not an unrealistic proposition if you build a great application with broad appeal and leverage all of the viral integration points available. You should aim for the mid-point of the Continuum of Scalability Preoccupation: more than releasing an underengineered prototype, but less than worrying about handling three million messages per day.

---

^[7] http://scobleizer.com/2008/05/31/clearing-the-air-with-twitter/