Scalability as a business problem: meet product limits
Scalability and performance are key concepts in product development, appearing in many conversations. However, it is often ignored how our product scales, leading to unexpected problems every time we face situations like a spike in the number of users or large customers using our product. Why does it happen?
Let's start with some definitions:
- Performance measures the speed/latency of a single request to our system.
- Scalability measures the ability of our system to maintain its performance under increasing load.
We can appreciate the difference in the image below:
In my experience, performance and scalability are often considered something technical, “non-functional” requirements completely managed by technical people. Only members of development teams participate in discussions about these concepts so there are not any business objectives related to them.
This lack of business objectives leads to several undesirable situations:
Teams only work in a reactive way. This is a common situation, where teams only have a reactive approach when some scalability problems appear. Usually, this happens as an incident, resulting in stress, anxiety, and poor solutions.
Teams invent scalability objectives: it's really common to have development teams working on scalability problems to support a workload that does not actually exist. This is a waste of time, as we are not adding any value to the product and we may never reach that load. \
Misunderstanding about the current capacity of the product between different departments.
The objective of product limits is to set boundaries in our product in order to avoid these unexpected situations. We want to move those scalability and performance conversations from a technical problem to a business problem.
Product limits should be set in a multidisciplinary exercise, with people from different departments providing context.
A possible exercise:
Choose one feature of your product
Get a rough idea of how much load it can support without degrading its performance.
Discuss that load, taking into account the business objectives:
a. Is it something acceptable for all departments? Is the current maximum load in line with the business goals? In that case, set a product limit. This limit can be a soft limit, inviting users to contact us if they have different needs. If this happens, we will have the opportunity to learn about that use case, but we will avoid unpleasant surprises.
b. Isn’t something acceptable? Does the current maximum load not meet the business needs? It’s ok, it's the first time we're doing this exercise, so we might have existing misunderstandings. In this case, we can also set the soft limit, but we will set a business objective to improve the scalability of that feature. Improving the scalability of that feature will be treated as any other new feature in our product.
The user experience is completely dependent on the product's performance and scalability, so it makes no sense to isolate these problems within development teams and leave other teams without any knowledge about them.
With product limits, we have seen an approach to move these concepts from a technical to a business perspective, where all teams collaborate to set limits that make sense for the product.
Have you ever run into this problem? Do you have any experience applying product limits or other similar solutions? Contact me and share it!
Share this post!
Thanks for reading this post. If you think it can be interesting for some other people, feel free to share this link with anyone you want. Also, you can use the links below to share it on Twitter, LinkedIn, or Pocket.