Presumably without throwing in a bunch of new and untested tech at the server level, this would involve shoving everything behind a defensive CDN to enforce queueing. Once you've got it in place it's a great way to make sure your static pages are always accessible under any kind of volume, but it isn't particularly cheap. The actual numbers of people who will have been hitting the servers probably wouldn't have been a challenge to serve simple static pages to anyway. The problem is further down the line when you hit the transactional pages - the SSL cert adds cost and complexity to the CDN setup if you still choose to run the traffic through the CDN. You also can't cache much transactional stuff at the edges so there isn't a whole lot of benefit for your expenditure in day-to-day use. In most environments I wouldn't even try getting approval to get that live on a site which doesn't often have massive peaks. What you're left with is a static site under protection, but with thresholds for the protection to kick in designed to protect the static site. That means the whole transactional site can be in pieces but the CDN still has no idea it needs to do anything. While you could have protected the static site and made people queue up to even get a link to the transactional site, if you didn't get that live straight away then the ship has sailed - everyone will just be hitting refresh direct on the transactional site (or have 5 tabs open hitting auto-refresh), and all your work was for nothing. Sadly the music industry doing it hasn't really helped anybody much apart from touts, who are now able to clear the whole allocation in about 5 minutes instead of an hour as previously. It would be outrageous to suggest that Ticketmaster did that deliberately just so they could double-dip with the Stubhub commission as well, but I wouldn't be surprised if some shameless cynics out there made that connection.