Last year, the Bruery's release party for Black Tuesday was so insane that after two-plus hours in line, I hadn't moved; the line wrapped around behind the building and back, and while patience was the rule, it was hugely aggravating. I finally gave up and left, unable to wait until 10:30 p.m. for a beer. This year, the staff decided to try and ease the madness by holding two time-limited parties at their tasting room in Placentia and to limit the attendance by selling tickets. Those tickets went on sale at 9 a.m. yesterday.
They didn't actually go on sale yesterday morning, though, because five minutes before the on-sale time, their web host's servers crashed under the crushing load. (If you were affected by this, know that the reservations will go on sale at 9 a.m. today.)
The same thing happened when reservations for LudoBites 5.0, the hugely popular (and delicious) pop-up restaurant went on sale; the software quailed under the onslaught and Krissy Lefebvre, the front of house manager, spent the next several days being insulted via e-mail by people whose collective self-worth had apparently been flung onto the dung heap by this failure of technology.
In that spirit, then, an open letter to hosting companies:
]
Dear web hosts of the world:
Welcome to 2010 and the future we dreamed of in 1995. Internet access is widely available, bandwidth gets cheaper by the day, and e-commerce and instant ordering have revolutionized not only business plans but the public's perceptions of how things work. It's been this way for a while; the novelty of online reservation has long since worn off.
So how is it possible that you don't seem to have figured out how to manage this? How have you not tumbled to the idea of demand-based architecture? It seems so obvious that the graph of connection attempts over time for a popular, advertised commodity such as The Bruery's Black Tuesday or LudoBites 5.0 would climb rapidly an hour before the on-sale time, spike massively starting about five minutes before, remain high for a time and then drop off considerably.
Well, if you can graph it, you can plan for it, and if you can plan for it, you can overplan for it. Sites like Ticketmaster have managed to implement a queuing system, where the only information that's passed through is a number in line; a separate system is passed requests and processes them as it's able, and people wait their turn, just like in meatspace under that burning yellow ball. I fail to see why web hosts who compete for this sort of business can't seem to deploy something similar.
“Server too busy” errors ought, like “NO CARRIER” messages, to be consigned to the dusty scrap heap of technological history. Businesses are trusting their images to you; when your system fails, their brands suffer. If you can't handle the potential load, you owe it to your clients to say so and allow them to make the decision whether to proceed.
Proper prior planning prevents piss-poor performance.
