Pingdom Home

US + international: +1-212-796-6890

SE + international: +46-21-480-0920

Business hours 3 am-11:30 am EST (Mon-Fri).

Pingdom Blog

Royal Pingdom

Ramblings from the Pingdom team about the Internet and web tech

RSS Feed

Facebook as a single point of failure for the Web

Facebook at the center of the web

If Facebook has its way (and it usually does), over the coming years a ton of websites and online services will become part of the open graph that Facebook is promoting, with Facebook firmly planted in the middle. The concept is very interesting, and the potential for this web of data from a wide variety of sources is enormous. You could say that Facebook will tie all our information, and the whole web, together.

There’s just one problem (two, if you count privacy): When the web becomes “interconnected” with Facebook, it also means that when Facebook breaks, the web breaks. In short, Facebook becomes a single point of failure for the web.

Can Facebook deliver on reliability?

Any site that relies on Facebook’s API to function properly will be in trouble if Facebook has any service issues (it’s happened before and it will happen again). This is true today, and the more integrated services become with Facebook, the more noticeable it will become.

Since the sites connecting to Facebook will be using the new Facebook Graph API, the reliability (i.e. uptime) and performance of this API will be critical.

A couple of days ago we set up monitoring of this API (with our uptime monitoring service) to see how it will perform over time. We’ll definitely follow up with a deeper performance and reliability analysis when this monitoring has been running for a while, but we already have some interesting results to share:

Geography and performance

On the internet, not all locations are created equal. Since Facebook is hosted in the United States, accessing the Facebook API will be faster in North America than other places of the world. Case in point, when we examined our monitoring results we could clearly see how accessing the API from Europe was significantly slower than from North America, all thanks to the overhead of distance. This is a direct effect of Facebook being hosted in the United States.

Here is the average time to complete a Facebook Graph API request. The chart is based on more than 3,000 requests from multiple locations in Europe and North America, spread over the last couple of days:

Average time to complete a Facebook API request
Above: Based on monitoring from multiple locations in North America and Europe between April 27-29, tests performed once per minute.

An average 340 ms in North America versus 569 ms in Europe is a pretty big difference, although as we mentioned, since Facebook is hosted in the United States, this should be expected. Nevertheless, Facebook API requests are on average 67% slower in Europe than North America, and this is something that we’ll simply have to live with (at least for now).

Uptime, though, proved impeccable (100%), although since we have only monitored the API for a few days so far it’s too short a period to draw any relevant conclusions about reliability. Regardless of the results, we feel pretty safe to say that unless a website is intrinsically connected to Facebook and has to depend on it, it’s probably a good idea to make sure that the site works ok even if Facebook is down or has performance issues.

Dare we trust Facebook?

The Open Graph is a brilliant concept and the potential for what can be done using this graph of knowledge and social connections (because that’s what it comes down to) is huge. And that potential goes way beyond customized web pages.

Some things benefit greatly from having a central repository, a central connection mechanism, and this is certainly one of those. If Facebook should be that entity is another matter, but regardless of who is in control, having one central point if failure can cause a great deal of problems once something goes wrong.

This central point of failure may be an argument just as strong as any privacy concern for decentralizing the open graph (and APIs used to access it). If it reaches the popularity many expect, it will be such a critical element of the web experience that it probably shouldn’t be controlled by any one company or service. On the other hand, it’s kind of what Google did with Search.

Want to test your site every minute?








You will get an email with your login information.

8 Comments

Reminds me of the old days when people thought AOL was the internet…

Facebook thinks pretty highly of themselves, huh? This is way more credit than they deserve. If Facebook disappeared right now, the internet would not even notice.

This post wasn’t really about “right now”, though. It was about the situation we might be in if Facebook really becomes the hub of the “open graph” and a large portion of sites decide to integrate that with their own functionality.

It will be interesting to see what takes Facebook’s place. Sure, its one of the fastest growing sites, but big things go down hard. Whats the saying? The bigger they are, the harder they fall. Just like MySpace, it was once the Top Dog, now look at it. Also, the Facebook connect thing is pissing me off. I had a Facebook account, but deleted it because I don’t want them owning my life.

It’s curious, isn’t it? The internet was specifically designed to NOT have a single point of failure. And yet now we are centralizing everything. To see why this is so, go here:

http://freemeet.com/blog

At least, these are my thoughts as to why that is happening with social media in general.

Greg

No news is good news for the Super Bowl website

The New England Patriots held what seemed to be a commanding lead (17-15) with five minutes left of Super Bowl XLVI last night. But the New York Giants came back and managed to win with 21-17.

As exciting as the game sounds, we missed the whole thing, instead spending our time watching the Superbowl.com website.

It turned out to be a rather dull thing to do because the site held up well and there was no downtime at all. The response time also didn’t give away anything significant in terms of online Super Bowl traffic.

Read more

As Super Bowl 46 is approaching, fans will flock to the Lucas Oil Stadium in Indianapolis, Indiana, and to TV sets around the world to follow the New York Giants battle it out with the New England Patriots.

Kickoff is scheduled for 6:30EST on Sunday, February 5, and we’re already monitoring Superbowl.com to see how the site will handle the event.

What team will win Super Bowl 46? How will the site cope? We can only wait to find out.

Read more

Weekend must-read articles #2

Every Friday we bring you a collection of links to places on the web that we find particularly newsworthy, interesting, entertaining, and topical. We try to focus on some particular area or topic each week, but in general we will cover Internet, web development, networking, performance, and other geeky topics.h

This week we bring you a collection of articles focusing on cloud, with a few other topics thrown in to boot.

Read more

Out of the 59 US-based e-commerce sites we monitored during the holiday season last year 28 scored a perfect 100% uptime for December.

Whether this helped spur on the booming sales in the US, we don’t know, but retail e-commerce spending in the US reached $37.2 billion for the November to December 2011 period. That was an increase of 15% from the same period in 2010.

We decided to dig into the numbers for these e-commerce sites to see how well they did in terms of uptime and performance. After massaging the data coming from our Pingdom probes, it turns out that the sites overall performed well during December 2011 in terms of uptime, but response time was an issue for several sites.

Read more

Pingdom Podcast #5

Pingdom’s Mobile Podcast is a weekly show about Internet, web, and mobile stuff.

In this show, Saleh also gives us an update on the pending submission of his Carbon for Windows Phone Twitter client. We’re also joined by Mario Lurig, who talks about using Amazon S3 and Cloudfront to speed up a website.

Read more