How is Chicago Boss different from Rails/Django/Mason/CakePHP/My Favorite MVC Framework?
Chicago Boss is fully asynchronous, using one single process to handle hundreds or thousands of simultaneous requests, and thus it solves the classic c10k problem. All other web frameworks will break down and cry if you ask them to process more than a few dozen simultaneous requests on a single machine. Chicago Boss is built with Erlang, the same platform used by banks and telecoms to achieve unprecendented scalability and (no exaggeration) 99.9999999% reliability.
The Nine nines of reliability often quoted is for the availability of a complete distributed system, including maintenance downtime.
A typical single Ericsson AXD 301 switch had a target of 5 nines of reliability without network redundancy, which is 5mins/year, including planned outages. see http://www.erlang.se/publications/Ulf_Wiger.pdf
One of the advantages of these switches was that they could manage 95% throughput at 150% load (Throughput then drops linearly to 40% at 1000% sustained load), which is also extremely useful, although not mentioned often.
Of course, this is the problem you get once you've solved the hard problems already, which is how to get that many visitors in the first place. At this point you have the money to buy a bunch of servers, typically, so this is aimed at people who are really great at getting incredible numbers of hits, but really poor at monetizing them.
It depends ... say you've got a nice project going on, still in infancy, and you post its link on sites like reddit and HN to get feedback. 2000 visitors instantly hit the link and your site crashes exactly when you need it more to stay alive.
Premature optimization is the root of all evil and all that, but going at the other extreme is equally not the smartest thing you can do.
An application like 37signals Basecamp can grow organically over time as the application is maturing and more and more users discover it and start paying for it. But if your project's success depends on the number of users you have (e.g. a social app), it makes sense to think about scaling and reliability a little beforehand.
Remember Twitter? It's still a mystery to me how this app survived having so many outages. Maybe they where lucky, maybe the social aspects where worth it for its users, but that doesn't mean your application will survive if facing such problems.
