Architectural Scalability

The scalability of a system includes its ability to handle large numbers of active users. For example, a Web site that fails to respond if more than ten Web browsers request a page at roughly the same time isn t particularly scalable. Conversely, a Web site that can handle hundreds or even thousands of simultaneous users and can handle periods of peak usage without crashing or causing time-outs is scalable.

The level of scalability of a system needs to be decided early on in a project. Scalability is a nonfunctional requirement, and nonfunctional requirements are notorious for affecting the architecture in often quite severe ways. YAGNI, DTSTTCPW, and no BDUF ^[14] are very bad mantras for projects that need to scale.

So, at a very early stage, the project manager and programming team need to determine (whoops, this is XP ”the customer needs to determine) how scalable the system needs to be. How many total users can it support? How many users can connect at the same time? Are there peak usage times?

Of course, these decisions can be reversed later, but at a cost. Despite the plethora of hype indicating otherwise , XP doesn t flatten the cost of change curve, particularly when it comes to nonfunctional requirements (the danger, of course, is that customers, believing the hype, might sign up for an XP project thinking that they can defer these decisions until much later. Caveat emptor ”let the client beware).

^[14] The XP mantras you aren t gonna need it, Do The Simplest Thing That Could Possibly Work, and [Don t do a] Big Design Up Front are all described variously throughout this book.