When adding new features that dramatically change how users interact with your site, it is a good practice to determine up front if your service can handle these new kinds of interactions so you don't end up constantly disabling features due to the high load they incur on your site. 

A couple of weeks ago, the developers at Facebook posted an entry about the architecture of Facebook Chat (it's written in Erlang, OMFG!!!) and I was interested to see the discussion of how they tested the scalability of the feature to ensure they didn't create negative first impressions when they rolled it due to scale issues or impact the availability of their main site. The relevant part of the post is excerpted below

Ramping up:

The secret for going from zero to seventy million users overnight is to avoid doing it all in one fell swoop. We chose to simulate the impact of many real users hitting many machines by means of a "dark launch" period in which Facebook pages would make connections to the chat servers, query for presence information and simulate message sends without a single UI element drawn on the page. With the "dark launch" bugs fixed, we hope that you enjoy Facebook Chat now that the UI lights have been turned on.

The approach followed by Facebook encapsulates some of the industry best practices when it comes to rolling out potentially expensive new features on your site. The dark launch is a practice that we've used when launching features for Windows Live in the past. During a dark launch, the feature is enabled on the site but not actually shown in the user interface. The purpose of this is to monitor if the site can handle the load of the feature during day to day interactions without necessarily exposing the feature to end users in case it turns out the answer is no.

An example of a feature that could have been be rolled out using a dark launch is the replies tab on Twitter. A simple way to implement the @replies feature is to create a message queue (i.e. an inbox) for the user that contains all the replies they have been sent. To test if this approach was scalable, the team could have built this feature and had messages going into user's inboxes without showing the Replies tab in the UI. That way they could test the load on their message queue and fix bugs in it based on real user interactions without their users even knowing that they were load testing a new feature. If it turned out that they couldn't handle the load or they needed to beef up their message queuing infrastructure they could disable the feature, change the implementation and retest quickly without exposing their flaws to users.

The main problem with a dark launch is that it ignores the fact that users often use social features a lot differently than is expected by site developers. In the specific case of the Replies tab in Twitter, it is quite likely that the usage of "@username" replies would increase by a lot once the tab was introduced since the feature increased the chance that the recipient would see the response compared to a regular tweet. So the load from the dark launch would not be the actual load from having the feature enabled. So the next step is to introduce the feature to a subset of your users using a gradual ramp up approach.

During a gradual ramp up, you release the feature set to small groups of users preferably in a self contained group so you can see how users actually interact with the feature for real without bringing down your entire site if it turns out that their usage patterns greatly exceed your expectations. This is one of the reasons why Facebook Chat was gradually exposed to users from specific networks before being enabled across the entire site even though the feature had already been dark launched.

Another common practice for limiting the impact of certain features from impacting your core user experience is to isolate your features from each other as much possible. Although this should be a last resort, it is better if one or two features of your site do not work than if the entire site is down. The Twitter folks found this out the hard way when it turned out that traffic from their instant messaging interface was bringing down the site and finally resorted to disabling the ability to update Twitter via IM until further notice.  Ideally your site's APIs and Web services should be isolated from your core features so that even if the APIs are going over capacity it doesn't mean your entire site is down. Instead, it would mean that at worst access to data via your site's APIs was unavailable. The same applies for ancillary features like the Replies tab in Twitter or Facebook Chat, if that service was overloaded it shouldn't mean the entire site should be unavailable.  This is one area where following the principles of service oriented architecture can save your Web site a lot of pain.

Now Playing: Earth, Wind & Fire - Let's Groove