Capacity Planning and Load Testing with k6

A load test applies the traffic you expect, such as a normal peak, to check that the service meets its SLO. A stress test keeps pushing past that point until something breaks, so you learn the real limit and how the service fails. You need both: the first proves you are safe today, the second tells you how much room you have.

Arrival-rate executors start new requests at a fixed rate whether or not earlier requests have finished. This copies real users, who do not wait politely for a slow server. Fixed-user (closed model) tests slow down automatically when the server slows down, which hides the overload you are trying to find.

A common starting point is to run at no more than 60 to 70 percent of the tested limit at peak. The rest absorbs traffic spikes, a lost zone or node, and slow scale-up. Tighten or loosen the number based on how fast you can add capacity and how costly an outage is.

You can, but only with care: low and ramped traffic, test accounts, no real payments or emails, and a kill switch. Most teams run full-scale tests in a production-like staging environment and use small, controlled tests in production. Never run your first stress test against production.

No. Autoscaling reacts to load, but it is limited by scale-up delay, node availability, quotas, and downstream limits such as database connections. Capacity planning sets the safe ceiling and the minimum baseline that autoscaling works within.