It is harder to control without a login.

Another option is to protect the site with an “access key” that you can then give out to your beta users. I personally don’t like these and they will inhibit initial expansion of your site since all users will need this key and the site won’t be indexed by Google etc.

Your best be is to do some load testing. Address the bottlenecks in your code and have a scale out plan if you think it will expand quickly. You need to have this plan ready so you can just click a button and add another load balanced server etc.

What is your bottleneck?

Assuming that bandwith is your problem, e.g. by serving high-res images, then using a CDN will be beneficial.

If your site is computationally expensive, then load-balancing between multiple servers sounds like the way to go. Hosting your webapp in a cloud will make this scaling easier, and you can always scale down or move to a conservative solution when you can accurately estimate the number of users. Scaling across multiple servers can get difficult if the users interact with each other using your site. In that case, peer-to-peer communication between users, or a message queue between your servers sounds like a good idea.

You might want to tweak your technology stack towards better performance. Static content can be cached. If you are running an interpreted language on the server, an alternative implementation may have a better performance profile (possibly trading start-up time or memory for overall faster execution). There is no excuse for using CGI scripts in this day and age for a modern webapp.

I don’t know how you will roll out your site. If you are targeting an international audience, one possibility would be to release the site at a certain local time for each user. A variation of this would be to display the site as closed to a certain percentage of IPs when load is high. However, requiring an email address to log in would actually be preferable. If load is high, tell the user he’ll get the activation email in about ten minutes (but then, give him priority). You could also give out URLs with an access token to specific individuals before officially opening the site. You can then try to estimate public interest from various metrics like percentage of people that used their tokens, number of tweets, ….

A controlled launch can be achieved by giving each pre-opening user a number of further tokens, which he can give away. This allows you to adjust the rate of expansion, until you open to the general public. Be careful with such tactics: while artificial scarcity can increase interest, this also makes it harder to your product to “go viral”.

If there are few fixed slots for users available, you could display their position in a waiting queue and perhaps give a clue on the remaining waiting time. How you can reduce the perceived waiting time is an interesting UX question.

In the end, this is not only an interesting technical question, but also a matter of marketing.

As a newbie to this site and the risk of not knowing proper etiquette, why don’t you design the application with scale-out in mind, immediately. Start with a scale-out NoSQL or similar database on the back end, caching layer below the site, distributed services that scale automatically (SOA, if you will) or as someone says at the press of button. The window of opportunity is narrow on things, why not plan for fast expansion and catch the wave versus trying to control users. There are software frameworks that you can build with right now, depending on what technologies you need, that have scale out in mind.

Use a Load Balancer to direct traffic to two sites, one being the live site, the other being a welcome page with a friendly message asking the visitor to try again later…