A major consideration when designing systems is scalability. Here I will detail the different dimensions of scalability that should be considered when designing a system. For every dimension I will try to give a software design example, and a humans system design example.
I am writing this post now, as it will be referenced heavily in my Unwritten Coding Standard series, the first of which is up here
Will my system be able to support N customers? This is often the form of scalability that people think of first when they consider scalability. A majority of the time when we are designing for Customer Count Scalability we employ the concept of “Horizontal Scalability”. We design our systems in a way that allows us to seamlessly run copies of the system in order to support more customers.
Examples of Customer Count Scalability include:
Can my design grow to meet new requirements? It is inevitable that the assumptions used to design a system will change over time. Good designs can adapt gracefully to support changes in the underlying assumptions. Often this takes the form of “modularity”, if requirements are sectioned off into modules then the effect of any change in requirements can be reduced to a single module.
Examples of Requirements Scalability include:
Can my system be maintained by more than one person? Where does the design break down as we begin to add more maintainers. A system should be designed with clear separations of concerns to allow for maintainers to make changes independently of one another. This allows for more maintainers to be added without creating bottlenecks.
Examples of Contributor Scalability Include:
Can we charge the most active customers the most money? This concept of scalability is less about systems design, and more about business model design. Does your business model scale such that the customers who are getting the most value out of your product also pay the most for it?
Examples of Cost/Charge Scalability: