What is the difference between load, stress, soak and spike testing?

All four use the same tools and often the same scripts. What changes is the load profile and the question you are trying to answer. A strong answer names the question, not just the shape.

Load testing

Question: does the system meet its performance targets under expected traffic?

Ramp up to the expected production load, and usually to the expected peak (for example a sale or month-end), hold it, and compare response-time percentiles, error rate and throughput against agreed targets (SLOs). This is the baseline test you run most often and use for regression comparison between releases.

Stress testing

Question: where is the limit, and what happens when we cross it?

Increase load step by step beyond the expected peak until something gives: latency climbs sharply, errors appear, or a resource saturates. The valuable output is not only the breaking point but the failure mode. Does the system shed load gracefully with 429/503 responses, or do timeouts cascade into other services? Does it recover by itself when load drops?

Soak (endurance) testing

Question: does the system stay healthy over time?

Hold a realistic load (often around normal production levels) for hours. Problems that only show over time: memory leaks, connection pool or file handle exhaustion, growing queues, disks filling with logs, slow degradation from caches or database bloat, scheduled jobs colliding with traffic. Watch trends in memory, GC and latency, not just the final numbers.

Spike testing

Question: what happens when traffic jumps suddenly?

Jump from low to very high load in seconds, hold briefly, and drop back. This tests autoscaling reaction time, cold starts, connection storms, rate limiting and queue buffering, plus recovery afterwards. A flash sale, a push notification or a retry storm after an outage all look like spikes.

Profiles at a glance

Load:   ramp ──── hold at expected/peak ──── ramp down
Stress: steps ↑ ↑ ↑ ↑ until it breaks, then observe recovery
Soak:   ramp ──────────── hold for hours ──────────── ramp down
Spike:  low ──┐ very high ┌── low
              └──────────┘

Related terms you may hear: capacity testing (how many users or requests per second can we support within targets, close to stress) and scalability testing (does adding instances increase throughput proportionally).

Practical notes

• Run in a production-like environment; results from an undersized test environment don’t transfer linearly.
• Monitor the system under test during every run (CPU, memory, database, queues), otherwise you get numbers without explanations.
• Make sure the load generator itself is not the bottleneck.

What interviewers look for

• The purpose of each type, not just the load shape.
• Typical defects each reveals: leaks for soak, scaling lag for spike, failure modes for stress.
• Awareness of environment realism and monitoring.