Photo by Martin Katler on Unsplash

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.

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    Architecture & Process Review

    Built a serverless app on AWS, but struggling with performance, maintainability, scalability or DevOps practices?

    I can help by reviewing your codebase, architecture and delivery processes to identify risk areas and their causes. I will then recommend solutions and help you with their implementation.

    Learn more >>

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>