Question 195 / 200Intermediate No code

What does a real load/performance testing methodology look like — what do you actually measure and how do you design the test?

Load testing isn't 'hit the API a lot and see what happens' — it's a designed ramp with explicit pass/fail targets, tail-latency percentiles, and a careful eye on the workload model itself.

LEARN BY DOINGPut your intuition to work3 steps

Before reading the guide, write your answer with one concrete example.

Use the lesson’s examples and explanation to check your idea.

Personal reflection. Nothing is sent to an AI service.

#Load Testing Answers a Different Question Than "Does It Work"

Functional tests answer "does the system produce the correct output." Load testing answers a completely different question: "how does the system's behavior — latency, error rate, resource usage — change as concurrent demand increases, and where does it stop scaling gracefully?" A system can be functionally perfect and still fall over under load because a connection pool exhausts, a lock becomes a bottleneck, or garbage collection pauses start dominating response time once enough requests are in flight simultaneously. None of that shows up by calling the API once and checking the response.

#The Four Shapes of a Load Test

Load test — ramp up to your expected peak traffic (e.g., "Black Friday, 3x normal") and hold it, to confirm the system meets its latency and error-rate targets at that level.
Stress test — keep increasing load past expected peak until something breaks, specifically to find the breaking point and how it fails (graceful degradation and clear errors, versus a cascading outage).
Soak (endurance) test — hold a moderate, sustainable load for hours, to catch problems that only appear over time: memory leaks, connection pool exhaustion, log disks filling up, slow degradation that a short test wouldn't reveal.
Spike test — jump traffic suddenly from baseline to several times normal with no ramp, to check whether autoscaling and connection pools react fast enough, or whether the sudden spike itself causes cascading failures.

#Designing a Load Test: The Shape Over Time

The ramp-up matters as much as the steady state: jumping straight to peak load hides how the system behaves while autoscalers, connection pools, and caches are still warming up, which is exactly the condition a real traffic surge produces. Holding a steady state for long enough (not just for a minute) is what separates a real signal from noise — short bursts can look fine purely because a connection pool had slack left over from before the test started.

#What You Actually Measure, and Why Each One Matters

Metric	Why it matters	Common mistake
p50 latency (median)	What a "typical" request experiences	Treating it as representative of the whole system — it hides everything in the tail
p95 / p99 latency	What your unluckiest users feel; often 5-10x the median under load	Only reporting the average, which a handful of very slow requests barely moves
Error rate (%)	Timeouts, 5xxs, and dropped connections as load increases	Not distinguishing client errors (bad requests) from server errors (capacity problems)
Throughput (requests/sec)	The sustained rate the system can actually process, not just accept	Confusing "requests sent" with "requests successfully completed"
Saturation point	The specific resource that hits its ceiling first — CPU, DB connection pool, thread pool, queue depth — and where latency visibly inflects	Not correlating app-level metrics with infra-level metrics on the same timeline, so you see that it broke but not why

#The Trap Senior Engineers Watch For: Coordinated Omission

Heads up

A closed workload model — where each virtual user waits for its current request to finish before sending the next one — quietly undercounts the pain of real degradation. If the server slows down, each virtual user issues fewer requests per second, so the load generator's own measured request rate drops exactly when things are getting worse, hiding the true tail latency behind a smaller sample of "responses that did come back." An open workload model — issuing new requests on a fixed schedule regardless of whether prior ones have returned — better reflects how real, independent users actually behave (they don't politely wait for the last click to resolve before making the next one), and surfaces tail-latency blowups that a closed model can quietly average away. This gap between measured and actual latency under load is often called coordinated omission, and it's one of the most common reasons a load test reports "looks fine" a week before a real incident with the same traffic shape.

#Designing the Test Itself: A Practical Checklist

Define pass/fail before you run it. "p95 under 300ms and error rate under 0.1% at 500 concurrent users" is a testable target; "let's see how it does" is not — you need an SLO to compare against, not just a graph to eyeball afterward.
Model realistic traffic, not uniform traffic. Real systems have a mix of cheap reads and expensive writes, skewed access patterns (some records are far hotter than others), and think-time between a user's requests — a load test that hits one endpoint uniformly as fast as possible tests something, but not what production traffic looks like.
Match production topology and data volume. A load test against a database seeded with 500 rows and a warm cache will pass regardless of query plans that fall apart at production's actual row counts; test against a realistically sized dataset, and consider testing with a cold cache at least once.
Correlate application and infrastructure metrics on the same timeline. Latency and error rate tell you that something degraded; CPU, memory, DB connection pool usage, and queue depth, viewed on the same time axis, tell you what actually saturated first.
Automate the critical-path version as a regression gate. A lightweight load test against key endpoints, run on a schedule or before major releases, catches performance regressions long before a stress test finds the absolute breaking point — you don't need the full stress-test suite running on every deploy to get value from load testing in CI/CD.

🧠 Check your understanding
0/2 · 0/2 answered
1. A load generator uses a closed workload model, where each virtual user waits for a response before sending its next request. What's the specific risk this creates?
2. Which metric best reflects what your least fortunate users are actually experiencing under load?

How do you reliably test async/concurrent code without flaky sleeps?What does chaos and resilience testing look like when it's baked into CI instead of a one-off game day?