Every test so far proves one thing: the app works for one user, you. But launch day, or a post that takes off, means hundreds or thousands of people hitting it at the same moment, and "works for me" says nothing about that. This chapter gets you a way to find out how much traffic your app can take before it slows down or falls over, while you can still do something about it.
8.9.1One user passing isn't many users passing
Your correctness tests answer one question: does it work. Load testing answers a completely different one: does it still work when a crowd shows up at the same moment.
The two never overlap. A checkout that passes every test for one shopper can still crawl to a halt when three hundred of them click Pay in the same minute. You will never see that by testing alone.
8.9.2A load test simulates a crowd
A load-test tool fires many fake users at your app all at once and measures how it holds up as the number climbs. Each fake user is a virtual user: the tool pretends to be one person hitting your app, then runs thousands of them in parallel.
The standard tool for this is k6. Your agent writes the script; you just name the endpoint and the peak. Here is the shape:
8.9.3Find the breaking point before users do
You push the load up until response times start climbing or errors start appearing. That number, the traffic level where it stops coping, is your breaking point, and it is the single most useful thing this test tells you.
Knowing it on a quiet Tuesday beats discovering it during your busiest hour. If it holds at five hundred users but buckles at six, you know exactly how much headroom you have.
8.9.4Test the path that matters, then fix the bottleneck
Do not load-test every page. Test the one flow a rush would hurt most: checkout, signup, or whatever core action your app exists for. That is where slowness costs you real customers.
When it buckles, the slow part is your bottleneck, the one piece the whole flow waits on. Finding and fixing it is a separate job, and the Scale part's chapters on bottlenecks and capacity are where you do it. This chapter only finds the limit; that is where you raise it.
This prompt sets your agent up to run the test:
Do this now: paste the prompt, name your one critical path and the peak you expect, and let your agent run the load test to find the number your app breaks at.
