Scalability in Tech: #1 - Why Stress Testing is Key

One of the key challenges tech companies encounter during growth phases—whether through marketing efforts or organic expansion—is scalability.

Put simply, scalability involves transitioning a piece of software from a developer's local machine, where it serves a single or few users user, to a production environment that must efficiently handle millions of users. Among the numerous strategies to ensure scalability, there's one I particularly advocate for: Stress Testing.

In my view, stress testing is the linchpin of the scalability process due to its quantitative nature. It answers critical questions like: How is the latency of my APIs? Are the database CPUs performing adequately? At what point do scenarios begin to fail? The metrics obtained from stress testing provide vital data that help us decide whether new features are ready for production deployment.

When conducting stress tests, there are two essential practices I always adhere to (or previous mistakes that I would like to avoid):

1. Scenario Design: Build test scenarios based on actual API usage patterns from the client application rather than just the specifications. Frontend developers often use APIs in ways that aren’t initially anticipated. Without tracing these API calls, stress test results may be misleading.
2. Parallel Testing: Run all scenarios simultaneously to simulate at least ten times the typical system load. Sequential testing doesn't replicate the concurrent demand of a production environment and can lead to inaccurate stress test outcomes. Implementing monitoring solutions is crucial to ensure visibility over these events.

While stress testing is not the sole factor in assessing scalability, it undoubtedly ranks highly in the CI/CD process, providing the necessary data to make informed decisions about the deployment of the latest code into production.

Do you have an opinion about this? please share your thoughts and experiences!