Load test
Firing simulated users at your app at the traffic you actually expect, then checking latency, throughput, and error rate against your targets.
See it
What it is
A load test fires simulated users (virtual users, or VUs) at your app on a schedule: ramp up to 500 over two minutes, hold, ramp down. The number you pick is the traffic you actually expect, or the traffic you are projecting for launch day, not an arbitrary beating. You watch requests per second, error rate, and latency percentiles, and you ask one question: does the system meet its targets at that level? Standard tools: k6, Artillery, Locust, Gatling, JMeter.
Run one before a launch, a campaign, or a migration, and set explicit pass conditions in the script (p95 under 400ms, error rate under 1%) so the result is a green or red build, not a chart somebody interprets. Its cousins share the machinery: a stress test pushes past capacity to see how it fails and recovers, a spike test slams traffic in instantly, a soak test holds moderate load for hours to surface memory leaks.
Gotcha: averages lie. A 120ms average hides the 3% of users waiting nine seconds, so report p95 and p99. Two more traps: a single laptop generating load usually measures its own network, not your server, and autoscaling plus cold caches make the first minute meaningless, so warm up before you measure.
Ask AI for it
Write a k6 load test for our checkout flow. Model a realistic journey (browse, add to cart, checkout) with think time between steps, and use a ramping-vus scenario: 0 to 200 VUs over 2 minutes, hold 5 minutes, ramp to 0 over 1 minute. Tag each request by endpoint, add thresholds that fail the run if http_req_failed goes above 1% or p(95) latency exceeds 400ms, and print a summary of RPS plus p50, p95, and p99 per endpoint. Point it at the staging URL from an environment variable.