With great power, comes great responsibility.

Your product is a success and now your business is seeing an explosion of growth. All of this growth is putting a strain on your tech. Recently, it is becoming more difficult to add more users to your product. There have been a few small outages. This is when you start hearing our team at Launchbase throwing the word ‘scaling’ at you.

But what do we mean when we say this?

And how can you make informed decisions about scaling your product?

So, what is scaling?

You should be asking ‘Will this scale?’, no matter what you are referring to. “Scaling” can be a loaded word. It can mean both everything and nothing at all.

What are you trying to scale?

The number of users your product can support?

Data throughput?

The hardware used by the app?

It is also important to note the difference between performance and scaling. Performance is the amount of work you can do with your existing resources. Scaling itself has multiple meanings, sometimes referring to increasing the amount of work the app can do or increasing the number of resources available to the app. Improving the application’s performance is one of several tools at your disposal to help solve scaling problems.

How can you scale?

There are many different levers our team can pull behind the curtain to help meet your scaling goals, some of which are more expensive than others. We have listed actions you can take and we would recommend following them in this order:

1. Define your goal

2. Identify and profile bottlenecks

3. Hardware

4. Optimising performance

5. Changes to architecture

1. Define your goal

Before we do any work, it is important to know what you are working towards. Any talk of “scaling”, an app is meaningless without any numbers attached. You need to compare:

We need to scale this app

vs.

– What changes do we need to be able to scale up to 100K daily users?

– We are onboarding a new supplier. We will need to be able to handle importing their catalogue of 10K parts into our system.

– Tickets for a hotly anticipated event are going on sale next week. Our ticketing system needs to be able to support the large influx of expected transactions in the first five minutes.

Improving performance and more resources might help you reach your goal. However, this will add extra cost and complexity if these improvements do not address the bottleneck.

2. Identify and profile bottlenecks

One of the worst things you can do is blindly make changes hoping for the best result. It is important to figure out what is causing the issues you have been seeing before making any changes.

– Is your database becoming overwhelmed?

– Is your web server running out of memory?

– Are you receiving too many web requests simultaneously?

– Are you getting rate-limited by a third-party service?

For the vast majority of web-based apps, the first bottleneck you see would be a database. Once you know what part of your system is slow, then you need to understand why and how slow it is. And not just in a qualitative “this is slow” sense. You want quantifiable measurements that you can use to compare before you and after we make the changes.

3. Hardware

If you keep adding users, there will come a time when you outgrow your hardware. Hardware is cheap, and cloud providers make it trivial to add more. Some places allow you to scale up hardware simply by dragging a slider.

Go ahead.

Upgrade to that database plan with a higher row limit. Increase your max RAM.

… Just make sure you identify your bottlenecks first.

Putting a faster web framework in front of a slow database may not have any measurable speed or throughput increases. Some bottlenecks can’t be solved easily by throwing hardware at them. For this, you may want to dip your toes into doing some performance optimisation.

4. Optimising performance

Once you understand the problem you might be having, it is time to make some changes. The cheapest solution is often to do some performance tuning. These are usually small code changes that allow you to get more work done with your existing hardware and architecture.

Keep in mind, tuning can also have some downsides. The general advice that our team can give you around caches and performance work in general, is don’t add one until you need it. Otherwise, you pay their cost without getting any value in return.

5. Changes to architecture

You will the point where your code is as efficient as it can be without adding more hardware. Now is the time to revisit the architecture of your application. This might be the time you want to start sharding your database or adding a read-replica. It might make sense to move to a streaming data pipeline. Re-architecting is pricey so you do not want to get it wrong, Always profile first and make sure you don’t have problems that can be solved with smaller-scale performance tuning.

Scaling can be a really intricate topic that can involve a lot of tradeoffs. There are countless technical solutions that can help you scale, ranging from single-line code changes to massive restructures of your digital product.

If you are facing product scaling challenges and would like to discuss specifics or you do not know where to start, get in touch!