可伸缩性，简单来说，是以更大的规模来做你现在所做的事。伸展一个Web应用的规模在于让更多的人使用你的程序。如果你没法找出方法在伸展规模的同时提高性能，没关系。而且只要你可以伸展规模来处理更大数量的用户，那么有几个单点故障（single point of failure）也没关系。
Royans解释说如今我们在面对规模伸展的时候有两个选择：
- 纵向的可伸缩性——在同一个逻辑单元内增加资源来提高处理能力。这样的例子包括在现有服务器上增加CPU，或者在现有的RAID/SAN存储中增加硬盘来提高存储量。
- 横向的可伸缩性——增加更多逻辑单元的资源，并令它们像是一个单元一样工作。大多数集群方案、分布式文件系统、负载平衡都是在帮助你提高横向的可伸缩性。
架构师们都在为达到线性的可伸缩性而挣扎，目的是让系统产出的增长与系统中投入资源的增长保持稳定的比率。然而，增加资源会导致一般耗费（overhead）的额外增长，因此难以达到线性的可伸缩性。Royans将之称为“伸缩性因子”，并用它来区分各种类型的伸缩能力：
- 如果在你扩大规模的时候伸缩性因子保持为常数，这种叫做线性伸缩性。
- 但很可能有些组件并不像其他组件那么适应规模的增长。小于1.0的伸缩性因子叫做次线性伸缩性。
- 话说回来，也可能因为增加更多组件而获得更佳的性能（在RAID系统中跨多个磁盘的I/O，当磁盘越多，性能越好）。这种叫做超线性伸缩性 。
- 如果应用程序没有专门为可伸缩性而设计，有可能当规模扩大的时候情况会变糟。这种称为负伸缩性。
跟软件开发中的许多事物一样，这里也没有适合一切情形的银弹可以解决你的伸缩性问题。Royans建议说，“如果你急切需要可伸缩性，向纵向发展可能是最容易的”，但注意“不幸的是纵向伸展会随着你的规模增长而越来越昂贵”，而且“无穷的横向线性伸缩性只是难以达到，而无穷的纵向伸缩性绝不可能”。他继续说：
从另一方面来说，横向可伸缩性并不要求你购买越来越昂贵的服务器。它的本意是用普通的存储和服务器方案来实现规模伸展。不过横向可伸缩性也不便宜。应用必须从建造的最底层就加以考虑才能在多台服务器上运行得像一台服务器一样。
Royans最后建议应该考虑所有的层次才能解决可伸缩性问题：
对于一个成功的Web应用，所有的层次都要同样能够应付规模的增长。包括存储层（集群文件系统、S3等）、数据库层（分区、联合）、应用层（memcached、scaleout、terracota、tomcat clustering等等）、Web层、负载平衡、防火墙等等。比如，如果你没办法实现多个负载平衡控制器来处理未来的网络流量，不管你在Web层的横向伸缩性上扔下多少钱，都不会有什么效果。你的流量始终被限制在一个负载平衡控制器能够承受的程度。