Why k6
Before deploying a new feature or endpoint that’ll see real traffic, I want to know how it holds up when multiple users hit it at once. k6 lets me script a realistic request chain — 10 sequential requests mimicking a single user flow and then scale that to see where response times start degrading.
How I Use It
At KnausDev, I write throwaway scripts that chain a few Laravel API requests together simulating a real user session, then ramp up the concurrency to find the breaking point. How many concurrent users before response times become unacceptable? Where’s the bottleneck — database queries, queue processing, memory?
On Exlink, load testing caught PostgreSQL connection pool exhaustion under concurrent expert search requests before it hit production. On Dadooo.ai, it validated that the multi-model AI endpoint handled parallel credit-tracked requests without race conditions.
The scripts are one-time — run the test, analyze the results, delete the script. It’s not a permanent test suite, it’s a pre-deployment sanity check. The insights feed back into the application — optimizing slow queries found under load, adjusting queue workers, tuning PostgreSQL connection pools.
In the Stack
k6 fills a specific gap in KnausDev’s infrastructure: the space between “it works in development” and “it works at scale.” Combined with New Relic or Datadog APM running during the test, I can correlate load patterns with application-level traces and pinpoint exactly what breaks first. Uptime Kuma monitors uptime after deployment — k6 validates performance before it.