The different dimensions of scaling

“But will it scale?” is a common retort when discussing architecture/technology selections or delivery processes for a software product.

On its own, this is a useless question since “scale” can have several dimensions that could influence engineering decisions. And crucially, many of these won’t apply to any single situation.

Let’s look at some of these dimensions:

• Throughput — we expect traffic to our product to grow fast and requests to come in large bursts
• Number of product features — our product needs to have a large set of features in order to beat our competitors
• Number of users — we plan to acquire a million users over the next 2 years
• Big data — very large volumes of data need to be processed within or stored in our system
• Big compute — our product has some specialised use cases which will require a large amount of processing power
• Size of codebase — we need to write a lot of code to deliver all of this
• Engineering team size — we need many engineers on our team to deliver all of this
• Finances — we need to pay for all of this and have a finite budget

Many of these scaling dimensions will have a causal relationship between them. For example, the number of product features will very likely affect the size of the codebase, and the number of active users will affect the throughput.

There can be negative relationships here too: as the size of the codebase grows, your ability to add more features may decline. Same if your team is slammed re-architecting the system to handle throughput demands. Software products are complex systems with trade-offs aplenty.

The key thing is to identify which of these scaling dimensions you care most about and which don’t matter so much. Only then can you start having more informed conversations and making decisions about the best technologies, architecture and processes to deliver them.