When the term scalable is tossed around, nearly 100% of the time it is used with respect to scaling systems up. There is a concern that the architecture will not work well or cease to function entirely if the scope of the problem it solves increases. This concern is twofold. First, the architecture will break and thus will not fulfill the purpose as intended. Second, time and money must be spent to redesign and rebuild the system to handle such a load.
Although a decrease in the scope of a specific problem would unlikely stress the solution in a way that would lead to breakage, some serious financial issues make scaling down efficiently a must.
The inability to scale usually has much more visible effects. When a site wants to scale up, it is from demand. Demand and the demonstration of customer growth are powerful factors in raising money and legitimizing investment in new technologies. So, when things need to scale up and they are implemented poorly, more often than not the organization will find the money to solve the problemeven if it is with brute force.
Scaling down is an entirely different matter. If the solution needs to scale back, an organization is doing so to respond to a decreased demand and usually wants to dramatically lower operating costs. Essentially, if there is nothing to be saved by scaling a solution back, there is no reason to do so.
Fundamentally, it is more difficult to scale an architecture up than it is to scale it down. Over-utilizing the infrastructure in an architecture has glaring usability effects, whereas under-utilizing it has only subtle financial effects.
Generally, it is much easier to scale back if you have gone through the process of scaling up (you can basically retrace the steps of your architecture's evolution). However, if you start big and need to scale down from there, it can be less apparent.
I know two companies that collapsed due to the inability to reduce operating costs when the utilization of their sites diminished. The dot-com user base (of intangible monetary value based on registered users) did not grow and generate revenue as expected. There was a substantial number of loyal users, and both companies were able to redefine their business plans to turn a profit by catering solely to their loyal user base. However, the business plans required reducing operational costs, and due to countless bad application design decisions, the applications would not operate on architectures substantially smaller than the large-scale originals.
Although the traffic and utilization of their architectures dropped to about 10% of the original goal, they were only able to realize a 20% reduction in operational costs. If the applications were redesigned from scratch, they could have scaled back, but an investment in redesign was not in their budgets. Both companies capsized.
Scaling down is good to keep in mind from an engineering point of view. Most online businesses faced with a 50% or more reduction in customers end up closing shop, so scaling down isn't often an important consideration. From an engineering perspective, it is a valuable exercise because engineers build solutions and the components that comprise them. Business goals change, and although the size of the overall solution may not change dramatically in scope, specific components may be sized up, sized down, or even become unnecessary.
One important rule of thumb is that adding independent components to an architecture complicates it linearly. Adding components on which other components depend to an architecture complicates it exponentially.