The scalability myth

At one time or another, nearly every kind of information technology has been judged and found wanting. The failures are often summed up in that most damning of epithets: "It doesn't scale." The reason, of course, is that at one time or another, for one reason or another, every kind of information technology has failed to scale.

Unfortunately for the victims tarred with that brush, scalability is a wildly imprecise term. Applications may be expected to scale up to massive server farms or scale down to handsets. And size is only one axis of scalability. Others include bandwidth, transactional intensity, service availability, transitivity of trust, query performance, and the human comprehensibility of source code or end-user information display.


It's tempting to conclude that the decentralized, loosely coupled Web architecture is intrinsically scalable. Not so. We've simply learned -- and are still learning -- how to mix those ingredients properly. Formats and protocols that people can read and write enhance scalability along the human axis. Caching and load-balancing techniques help us with bandwidth and availability. But some kinds of problems will always require a different mix of ingredients. Microsoft has consolidated its internal business applications, for example, onto a single instance of SAP. In this case, the successful architecture is centralized and tightly coupled.

For any technology, the statement "X doesn't scale" is a myth. The reality is that there are ways X can be made to scale and ways to screw up trying. Understanding the possibilities and avoiding the pitfalls requires experience that doesn't (yet) come in a box. [Full story at]
Based on the reaction so far, it seems like this piece went over well. It's so nice to be able to track reactions that way.

Former URL: