CNET también está disponible en español.

Ir a español

Don't show this again


Just a thought: To ensure success, plan for failure

Why site managers expect their servers to run flawlessly under load is beyond me.

The popular election prediction and tracking site posted an ominous message on top of a post Tuesday night:

Apologies in advance -- looks likely to about to pull an epic fail tonight on our most important night. I've been clicking publish since before 6pm central on one post, and the rest of the internet is lightning speed. Just looking at results and fruitlessly clicking "publish." We're here and trying to publish; just can't. They can't handle the traffic. Sorry everybody.
Ominous news from

While it looks like the trouble at FiveThirtyEigh was transient, one wonders what fallback plan site organizer Nate Silver had for a meltdown at their blog host. An alternate host? A stripped-down version of the site that puts less of a load on the blog publishing engine? Anything at all? It doesn't look like it.

Now, obviously, a site about the presidential elections doesn't want to go into limp-home mode on election night, but it would sure beat going offline.

Very few sites have fallback plans to deal with overload--or as we might call it, the agony of victory. But given how quickly a site's traffic can spike these days, due to a few fortuitous links on a referral site like Digg or CNN, one would think that the clever site manager would plan for them.

All I'm proposing is that publishers set up alternate templates for their sites, stripped of complexity and widgets and maybe even advertising. Yes, an ad-free version of a content site might leave money on the table, but better that than losing readers for good. And if the content is great, readers new to the site are more likely to come back, where they'll generate those monetizable impressions once again.

By the way, I've covered this topic before: On September 14, 2001, in my Catch of the Day column for Red Herring, I proposed that sites handling public safety information that find their bandwidth overwhelmed by requests adopt peer-to-peer technologies to get the word out even when their servers are swamped. In retrospect, that was too technologically hard to do and would still be hard today. Likewise, having a site that could be switched into a low-bandwidth mode at the flip of a switch is not trivial. Although, if developers took some of my other advice and created mobile-friendly versions of their sites, those designs could be used in overload emergencies and might serve the same purpose.