in general, you can "scale up" (buy bigger servers) for a little while, but eventually you'll have to "scale out" (divide the load across a lot of smaller servers.) amazon's EC2 service lets you do this relatively easily. it's hardly plug and play though; you have to figure out how to scale out within your app and ensure that you can split up your data across multiple servers, which is often not trivial. for example, even if you can partition your data, what if one "piece" gets hammered with a disproportionate amount of traffic (i.e. one particular photo album or whatever gets dugg/slashdotted); what if a server goes down; what if you need to dynamically add servers; how do you protect data if a disk completely fails; etc.
here's some food for thought from the sysadmins of livejournal and digg, and how they dealt with growth.
http://www.getdropbox.com/u/2/Interesting/servers%2C%20infrastructure/danga.com%20livejournal%20backend.pdf http://www.getdropbox.com/u/2/Interesting/servers%2C%20infrastructure/digg%20sysadmin%20presentation.pdf
perhaps better than the technical solutions are social solutions to hypergrowth: you can use invites, beta periods or waiting lists to control your growth instead of turning people away indefinitely, and also set users' expectations that things may go wrong and to bear with you. it's really tough to anticipate on the technical side where things will break if you're adding hundreds of k users; just look at ilike, which got rocked by f8 signups.
there are more pieces too besides just serving the http requests properly :P presumably you'll need to provide some support to these people, answer emails, fix things when they go wrong, have some method of discovering and triaging problems, etc.