Scalability does not make sense without context.
When asked about the scalability of a system, the first thing that needs to be known is the ways in which its utilization is expected to grow. Will it be getting more users? Will the existing users be making heavier use of it? Will its feature set be growing? Will the mix of transactions that it's presently supporting change? Will the user experience need to change?
(OK, so the answer to all of those questions is usually "Yes"; then
prepend the word "How" to those questions.)
For example: a system currently supporting very few users, and whose user base is expected to grow
rapidly, has a serious scaling problem if the DBA has to spend two hours manually running queries from information picked out of email messages every time he has to set up a new account. That's not a problem that can be fixed by adding more resources, unless you're including DBAs in the list of resources you're going to add (and there
are a lot of reasons that's not going to scale well).
Or imagine a social-networking site that rolls out the exciting new feature that you can see if your friends are online and chat with them through a nice Ajax-y UI. Suddenly, with no increase in the user base, the number of HTTP requests your servers are handling per day jumps twenty-fold, and your worries about the scalability of your database
recede into the background. (Unless, of course, you've involved the database in your chat application. Good thinking!)
Sure, making your web apps stateless so that you can add web servers, making web pages idempotent so that you can add proxies, designing your application so that you can partition your database across servers, those are all going to make your application scalable in various dimensions. It's very much worth thinking about that stuff.
