Load Testing: Find System Limits Before Customers Do

TL;DR — Load testing runs a realistic amount of concurrent work against a system to learn whether it meets an agreed service objective. It is useful only when the scenario, data, environment, and pass criteria reflect a real customer journey. Start with one important flow, measure the whole path, and increase scope after the result is explainable.

Load testing is often requested as a number: “Can it handle 1,000 users?” That is not yet a test. Users do different things, arrive at different rates, bring different payloads, and share databases, queues, caches, and third-party dependencies. A result without a traffic model is only a measurement of a synthetic script.

Grafana’s API load testing guide recommends beginning with isolated components and growing toward integrated flows, while its website testing guide distinguishes protocol load from browser experience. That distinction matters: a fast HTTP response does not prove a customer can complete the product flow.

Start with the decision the test must inform

Choose one of three decisions: validate expected demand, locate a known limit, or compare a proposed change to a baseline. Each needs a different load shape. A normal-load test should model ordinary concurrency and think time. A spike test examines a sharp arrival burst. A soak test looks for gradual degradation such as connection leaks or queue buildup. Calling every run a “stress test” makes results difficult to compare.

Write pass criteria before the run. They should include correctness as well as latency: successful completion rate, error type, queue age, database saturation, and the user-visible response objective your product actually makes. Do not copy universal response-time targets. A background export and a checkout confirmation have different expectations.

Model a real path, not a single request

Hypothetically, a B2B product expects a morning burst: users sign in, open a dashboard, filter a list, and create an item. A representative test uses varied test accounts and data, respects API rate limiting, and measures the read and write path separately. Hammering only the dashboard endpoint might prove cache throughput while missing the transaction that matters.

Keep test data separate and identifiable. Do not load test a provider you do not control without permission; third-party calls can create costs or trigger their own protective limits. Stub them where that preserves the behavior you need to measure. A test that does write actions needs cleanup and a ceiling that prevents a mistake from filling production-like storage.

Treat the environment as part of the result

A staging environment is useful for aggressive testing, but a small staging database, different cache topology, or missing background workers can make it unrepresentative. Production testing can be more accurate and more risky. When it is justified, use a reviewed, low-impact scenario, an off-peak window, live monitoring, and an immediate stop condition.

Record the infrastructure version, data size, configuration, test script revision, load-generator location, and results. Without that receipt, you cannot distinguish a real regression from a changed test or environment. This is also how a founder avoids buying capacity because one unrepeatable run looked alarming.

Find the bottleneck, then fix one thing

When a test fails, trace the limiting resource: database query time, database connection pooling waits, CPU, a queue consumer, cache misses, or a downstream service. Adding more application instances can worsen a connection-bound database. Adding an index might help a query but not a serial queue. Change one causal factor, rerun the same scenario, and compare results.

Failure modes to prevent

• A test script reuses one account and creates lock contention no customers see.
• The generator itself saturates, so results blame the product incorrectly.
• A test reports averages while a meaningful tail of requests fails.
• A pass result ignores background queues that are silently falling behind.
• A peak test hits a third party without authorization or a stop condition.

Acceptance checklist

• The test names the customer flow, demand model, data setup, and decision it will inform.
• Pass criteria include success, latency, errors, and the relevant downstream metrics.
• The environment and script revision are recorded with the run.
• The run has an owner, safety limit, and stop condition.
• Any improvement is re-tested against the same scenario and a baseline.

Load testing is not a certification ceremony. It is a repeatable way to replace a capacity guess with a constrained, observable answer before real customers carry the risk.