要是系统架构是伸缩性的，则系统应该是分布式的，并发的。就像书中讲到的Darkstar项目，由于在线人数，不同时间等的影响，游戏的负载情况也会不同，服务器的数量，连接方式，为了应对这些不同的情况，也需要实时变化。
举一个比较简单的例子，对于网站的开发来说，在网站开发的初期，我们会把代码写到一个文件夹下，也就是写道一个项目中，但随着网站的运行，很多数据和用户的请求不断增加，导致系统越来越大，这样就一台服务器实现就有困难。
软件架构的伸缩性是一个极为重要的特性，我们在将来的软件开发过程中必须要注意，系统的伸缩性，以免导致系统的崩溃。
于此同时，还讲述了一般情况下，处理拥塞的解决方案：
1. 基于地理位置来实现。游戏设计包含不同的游戏区域，每个虚拟区域运行一台服务器，每个区域拥有自我限制功能，当人数过多时，服务拥塞，游戏变慢，趣味性下降，用户就转向更有趣的区域，响应时间就会得到改进。（对于棋牌类游戏，每个房间或区域有人数限制，满的房间可以限制进入）
这种开发方法的问题：游戏设计时，需要决定哪些区域放在一台服务器上，而添加新的区域时比较容易，若改动原来的区域，可能需要改动代码，这些都是开发的工作量。
2. 分区sharding。一个分区是一个区域的副本，运行在自己的服务器上，独立于其他分区，不同的玩家进入同一个区域的不同副本（分区）。这样的缺点时，不允许不同副本的玩家彼此进行交互。
3. Darkstar架构就是克服以上缺点，支持随时伸缩，同时又不要求游戏逻辑受到伸缩影响。支持动态响应负载，而不是放在游戏设计中完成。