Recently, an organization (not any of mine) opened sales for their big event. This is one of those events where there's no way to put enough seats on the trains to satisfy all the demand. The desirable dates tend to sell out in minutes. Well, their website crashed.

Deconstructing it has been interesting.

They used an external ticketing company to do ticket sales, which could have helped, except... they said "Online sales only, no phone" even though the ticketing company has a call center and will happily do phone sales on your behalf. Also, the "Shotgun start" of ticket sales was at a time when the ticket company's call center was closed. Obviously the ticket company would have instantly discovered the problem for all the customers blowing up their phone, and would have either fixed it, or alerted the contacts they have at the railroad.

Just goes to show: even finding out about a problem is hard, in and of itself.

One customer had suggested "use EventBrite" which is a ticketing site for anyone. However, your ticketing page will be located on their site, eventbrite.com, and that bothers businesses. The more "pro" companies that serve railway preservation, like Whistletix, Vendini and Turnstile, allow you to have the professional appearance of tickets on your own site, by "framing" their ticket page within your own web page.

If your own site went down, that would make the ticketing pages inaccessible. Now, a simple website can easily handle a surge, since it's light work to hand out .HTML documents and a few .CSS and .JPG files.

However certain web design styles can put a lot of stress on the server, and render it unable to cope with a surge. One of those is use of a CMS (Content Management System) - stuff like Wordpress or Joomla. These allow easy editing and other flexibility, but they also generate each page from a series of database queries. A lot of database churn is required to serve even a "static" web page. Another database churner is "widgets" - on-page elements which are interactive, and require more database hits and computation. And this applies to every page on the site that the user needs to "hop to" to get from the homepage to the ticket buying page.

A lot of these widgets are free and written by amateurs. They are not pros, and don't think about computational efficiency, i.e. what will happen if the web server is serving the widget to 100 people at the same time, whether that will overload the database, etc.

I'm all for the flexibility of a CMS, but I think it should be limited to "deep content" like your Wiki, photo galleries, equipment or project detail pages, etc. Widgets on the homepage are cute, but efficiency has to be foremost on your mind.

You may remember on 9/11, CNN stripped down to the simplest possible plain-HTML page as its homepage.

A related issue is how long pages take to load these days. That's a recent trend - to pull in dozens or even hundreds of little "page elements" from a variety of sources. If you've ever seen a page "leap upward" after you scrolled down, the page was still loading and it inserted a new section above you. That's because the web page failed to tell the browser how much space to reserve for that element (whoops). Now, some sections are absolutely critical to rendering the page, e.g. the width of columns. If those sections don't have size declared, the server must wait until all of them have loaded before it can display anything at all! Now you know why your Facebook app's web browser is so slow. (they don't pre-specify sizes because the elements are ads.)

If your server is overloaded, "waiting" becomes "failing". Do the math: if your server is answering 80% of queries successfully, but you have 11 essential page elements needed to sell a ticket, the chance of a page load is only 8%. (0.8^11).

Another mistake that will cause overloads is hosting the web server on your premises or some member's house. I don't care how deluxe your DSL plan is, it's a choke point, and it's not anything like being in a real datacenter. Seriously, that is not a cost savings. Nevermind the cost of the server, software and support. Nevermind the cost of the DSL. Nevermind that security is a practical impossibility for anyone who doesn't send a 4-man team to DefCon every year. The cost of the electricity alone is more than you'd pay to host it somewhere good with security.

This is where things like Azure and AWS come in handy. Oh, and like industrial grade tools (and those who know how to use them).

However, for most RYPN readers, the answer for these problems is to outsource the ticketing solution, and then make sure there has been good thought and communication in place to avoid issues like you just described: opening ticket sales when nobody was in the office.

We've never had a problem. If I may offer some advice as a web designer: If you're going to use a ticketing service or sell your own tickets through your website, get familiar with server specs and choose your hosting provider carefully. Pay the few extra bucks for additional bandwidth. Geo-redundancy is also a plus - if a server goes down, another picks up the slack. You get that with some of the large hosting companies. Avoid CMSs if you can as they can be a resource hog. But those can be OK if you have enough bandwidth. Otherwise, stick with HTML web pages though if you don't have an HTML savy person in your organization, you'll have to pay one for updates. Bandwidth may also come into play with mobile-friendly responsive HTML5 - the content resizes and rearranges itself depending on the device the user is viewing the site with and requires more code to serve. Moral of the story, don't go cheap or small with your hosting provider.