Introduction: The Stakes of a Perfect Launch
For any product owner, launching a product is an exciting occasion, especially after months of painstakingly creating every feature. You are finally one step away from the big launch when all of a sudden a CxO poses a question that might change everything:
"How many users can it handle concurrently?"
Developer’s Approach
The immediate response often involves the DevOps team:
"Let’s discuss this with the DevOps team to understand how we can create an auto-scalable system to ensure zero downtime."
But is an auto-scalable system the solution to every system architecture problem?
The Realities of Auto-Scalability
The answer is a big "no." While auto-scalability is a powerful tool, it can unnecessarily increase infrastructure costs when it's not needed.
The Alternative: Instance-Based Solutions
A more traditional approach might involve a classic instance-based solution. However, this raises a new question:
"When should we consider scaling the system and the approach should horizontal or vertical?"
Challenges with Scaling
Using system-level warnings (such as those from Monit or other monitoring tools) is one way to solve this problem. But frequently, these signals only give a brief window of time to organize and carry out upgrades. This becomes more difficult when the product expands, particularly for B2B solutions where it might be practically impossible to anticipate overloads due to the enormous number of customers being onboarded at once.
The Solution: Load Testing
A load test must be conducted in order to address these issues. This method aids in determining the existing architecture's limitations. Like many developers, we suggested building a test suite to mimic large request volumes and identify the system's limitations.
Let's examine what, why, and how in more detail.
What is K6?
K6 is a developer-focused, open-source tool for evaluating your system's performance and resilience under stress. K6 was developed by Grafana Labs and provides easy scripting, powerful analytics, and smooth connection with development processes. K6 is a great option for developers as well as product owners looking to confirm system readiness because it places a higher priority on usability and simplicity than standard load testing solutions.
The Product Owner’s Perspective: Why K6?
Your main objective as a product owner is to provide a flawless user experience. K6 facilitates actionable and accessible load testing. Here's why it's so important:
1. Ease of Use
K6 uses JavaScript something with which most the developers are already familiar.
How is it different from writing your own scripts?
K6 allows you to easily convert existing Postman collections into K6 scripts:
npm install -D @apideck/postman-to-k6
postman-to-k6 collection.json -o k6-script.js
This generates a script like the one below:
import "./libs/shim/core.js";
import "./libs/shim/urijs.js";
export let options = { maxRedirects: 4 };
const Request = Symbol.for("request");
postman[Symbol.for("initial")]({
options,
collection: {
localhost: "http://localhost:33001",
},
});
...
Run the test script using:
k6 run k6-script.js
2. Actionable Insights
K6 provides clear, meaningful metrics that translate directly into business outcomes, such as improved uptime and user satisfaction.
3. Proactive Risk Mitigation
Identify bottlenecks and vulnerabilities before launch, saving time and money on post-launch fixes.
Simplifying the Complex: Key Metrics and Reporting
K6 focuses on metrics that matter:
Response Time: The most important aspect for any product owner.
Error Rate: Tracks the percentage of failed requests to understand where to set the limit.
Throughput: Calculates the number of requests handled per second to give us an idea about when to plan for our next upgrade.
These metrics helps the product owners to evaluate system health and pinpoint areas for improvement.
Tips and Tricks for Maximum Impact
To make the most of K6:
Start Small: Begin with basic API requests and gradually move towards complex systems.
Focus on Realism: Try to apply DDD(Domain driven design) to make sure it emulates a user who is going to use the system in future.
Automate Testing: Always move to CI/CD pipelines to make sure this run before each build to give you proper indication to pre plan the upgrade.
Analyze Trends: Analyze the change in the metrics to understand the system health impact with each release.
Conclusion: Build Confidence Before Launch
System architecture is the backbone of any successful product launch and it can also screw things easily if not taken care promptly. So always test before claiming the system’s capabilities i.e. Apply Show no tell methodology (by Mr. Swanad Pagnis). This way you will be able to have a good night sleep after the launch of the product.
Special thanks to Syed Hassanand Anuj Verma for suggesting K6 and sharing their insights into load testing.
