Your application works perfectly. APIs are fast, tests pass, and the CI/CD pipeline runs without issues.
Then real users arrive.
Login requests slow down, APIs time out, uploads fail, and CPU usage spikes. The application that looked production-ready suddenly exposes problems functional testing never found.
That’s when I realized:
Load testing isn’t just about measuring speed; it’s about finding bottlenecks before your users do.
Real users don’t repeatedly refresh a page. They log in, navigate, upload files, submit forms, and perform different workflows. To test a real application, your load tests must behave like real users.
In this article, I’ll share what I learned using k6 to simulate realistic traffic, manage authentication, chain APIs, monitor system resources, and identify performance bottlenecks before they impact production.
Why I Chose k6
I evaluated several load-testing tools before choosing k6.
The biggest reason wasn’t performance; it was developer experience.
Since k6 uses JavaScript, I could organize tests into reusable modules, manage authentication logic, generate dynamic users, and version everything alongside the application code.
That made maintaining and extending them much easier as the application evolved.
From Virtual Users to Real Users
One of the biggest mistakes beginners make is assuming that increasing the number of virtual users is enough to perform a meaningful load test.
It isn’t.
A thousand users repeatedly requesting the same endpoint doesn’t represent how people actually use your application. Real users authenticate, browse different pages, fetch data, upload files, submit forms, and interact with multiple services throughout their session.
To build a realistic load test, I first needed realistic users.
Step 1: Creating Dummy Users for Realistic Load Testing
Before I could generate realistic traffic, I needed realistic users.
A production application isn’t accessed by a single account making thousands of requests; it’s accessed by hundreds or even thousands of individual users, each with their own identity, session, and authentication token.
To simulate this behavior, I wrote custom automation scripts to create hundreds of dummy user accounts and store them in the application’s database through the authentication system. Each user had unique credentials, allowing every virtual user to log in independently during the load test.
The goal wasn’t just to create traffic—it was to create realistic traffic.
Step 2: Authenticating Every User
Creating dummy users was only the first step. To simulate real user behavior, every virtual user had to authenticate before interacting with the application.
My authentication workflow looked like this:
- Each virtual user logged in using its own unique credentials.
- The authentication service generated a JWT access token for that user.
- The token was securely stored and reused throughout the user’s session.
- Every subsequent request- loading pages, accessing protected APIs, submitting forms, and uploading files—used the same authentication token.
- If a user’s session expired, the script handled re-authentication to continue the workflow.
Step 3: Simulating Real User Journeys
After authentication, I avoided one of the most common mistakes in load testing: repeatedly hitting the same API endpoint.
Real users don’t behave that way, and neither should your load test.
Instead, every virtual user followed a realistic journey through the application, performing actions that closely matched everyday usage:
- Log in with a unique account.
- Load the dashboard and essential pages.
- Fetch user-specific data from protected APIs.
- Navigate between different modules.
- Create or update records.
- Upload files and supporting documents when required.
- Continue browsing and interacting with the application instead of ending the session immediately.
What I Observed
This is where load testing became truly valuable.
When users followed complete workflows instead of isolated requests, the application’s behavior changed. APIs that were fast on their own became slower when combined with authentication, database operations, and concurrent user activity.
I also learned that bottlenecks weren’t limited to the application. Authentication, database queries, file uploads, and network latency all affected performance, issues that isolated API testing would never have uncovered.
What to Avoid
From my experience, these are the mistakes worth avoiding:
- Don’t test only a single endpoint or homepage.
- Don’t reuse one account for every virtual user.
- Don’t send the exact same payload with every request.
- Don’t ignore authentication, session handling, or user roles.
- Don’t stop monitoring after response times; watch CPU, memory, database activity, and error rates as well.
The closer your virtual users behave like real users, the more meaningful your performance results will be.
Step 4: Scaling from Hundreds to Thousands of Users
Once the user journeys were realistic, I gradually increased the load instead of jumping straight to thousands of users. This made it easier to identify when and where performance started to degrade.
What I Observed
As concurrent users increased:
- Authentication requests grew rapidly.
- API response times increased.
- Database queries became slower.
- File uploads consumed more resources.
- CPU and memory usage climbed.
- Some services scaled well, while others became bottlenecks.
The biggest insight wasn’t that the application slowed down; it was understanding where it slowed down and why.
Understanding Resource Utilization
Scaling the load wasn’t just about generating more requests; it was about understanding how the system behaved under real traffic.
During testing, I monitored:
- CPU and memory usage
- Docker container performance
- Database query performance
- Error rates and failed requests
These metrics helped identify performance bottlenecks with data instead of assumptions, making it easier to pinpoint where the system needed optimization.
Why This Matters
One of the biggest lessons I learned is that load testing isn’t about finding the maximum number of users your application can handle.
It’s about understanding:
- Which service reaches its limit first.
- How many resources are required to support expected traffic.
- Whether additional CPU or memory is needed.
- Whether the database needs optimization.
- Which APIs require caching or better indexing.
- Which services should be scaled independently.
- Whether the current infrastructure is sufficient for future growth.
These insights make capacity planning much easier because every optimization is backed by real performance data instead of guesswork.
The Biggest Takeaway
When I started this journey, I thought load testing was simply about measuring response times.
By the end, I realized it was much more than that.
Load testing became a tool for understanding the entire system, from authentication and APIs to databases, containers, and infrastructure. It showed me not only how many users the application could support, but also what needed to change to keep the experience smooth as traffic continued to grow.
Mistakes That Made My Load Tests Unrealistic
While building production-ready load tests, I learned a few important lessons:
- Using one account for all virtual users instead of unique users.
- Skipping think time, creating unrealistic traffic.
- Testing only GET APIs instead of complete user workflows.
- Ignoring failed requests and focusing only on response times.
- Using static payloads that didn’t reflect real usage.
- Jumping straight to thousands of users instead of increasing load gradually.
The biggest lesson? A good load test isn’t measured by the number of virtual users; it’s measured by how realistically they behave.
Final Thoughts
Before building the load tests, I thought performance was something you measured after development.
Now I know it’s something you design for from day one.
A realistic load test isn’t just about finding the maximum number of users your application can handle. It’s about uncovering bottlenecks, understanding resource utilization, and optimizing your system before real users experience problems.
The biggest lesson I learned wasn’t how to use k6; it was how to think about application performance.
When hundreds or thousands of users access your application, they don’t care how well it worked on your machine. They only care that it works for them.