<Couple beers, apologies for typos>
2 & 3 are really the same question or at least could be. You first have to clarify what kind of application. a) small task, stateless processing (e.g., web-based photo conversion b) small task, statefull (e.g., uuhhh, can't think of anything..something smaller than an e-commerce site, like a local YMCA site where you can make reservations or imgur in its first couple years.) c) large task, stateless (e.g., streaming video encoding) d) late statefull (e.g., e-commerce site, bank)
People that ask this question usually mean D or B. The nice thing is that the answer is the same for both.
High level: To do anything at scale you have to separate concerns. Need to use some sort on multi-tier architecture. There are a bunch, many generally refer to a presentation layer (UI), application layer (the code you normally think..here be Java and C++#), storage (some form of persistence DB, disk directly, cloud based whatever)
Medium level: There's days' worth of conversation that can happen here, this is just one way to answer this question that makes sense to me. There are many others that are perfectly acceptable. Front End: Reduce load on the web servers first, take of all static content and push to CDN, minimize everything. Make sure that you aren't running default settings on your Apache server, max out that thread count for the hardware, take up 80% CPU on max load to start. Drop a load balancer and throw X number of server behind it and just round robin them. Store no state in memory, use the storage layer and let it do the work, don't make your load balancers do more work than they have to.
Application Layer: I'd start by running a service oriented architecture. This will help you scale because you've basically "meta-object oriented" your application. Conceptually, you can take a particular method in your code that gets called a lot and takes up a lot of CPU cycles and simply run that part of your application on different hardware. What's the penalty? Time. Service calls are orders of magnitude slower than local calls, but that generally doesn't matter with web-applications, could make something like WoW less fun. So now you can scale the individual "logic" pieces of your application completely independently from each other. Again, keep no state locally, round-robin the load balancers, tune the thread counts and memory. Done. Oh, and don't write shitty code that leaks memory connections or something else stupid that will bite you in the ass at scale.
Storage: This is the ugly part that makes all the difference and is really, really hard to get right. It isn't sexy down here, but I've found that this is what makes this difference between applications that are dogs and ones that really hum. So, don't pick the wrong storage solution. Also, use as many as you need. Don't try and store images in your relational DB as a BLOB. Only use a relational database for relational/transactional data. They are great at what they do, but not great for other things. If you can live with the concept of denormalized data then use a non-relational DB. They tend to scale well. Use appropriate caching wherever you'll get benefits. Hire someone that knows more than you about this to look at the mess you've made. This part really can't be answered without more details about what the data-load and usage patters would look like. You can hide from a lot of those details/push the complexity down in the architecture I've described above.
Low: <People don't usually need to go this deep in a question like this, but I guess you could talk about which OS you'd run on, custom kernel, GPU boxes, commodity hardware strategies. Not really sure what I'd expect down here.>