Why should a system undergo load and stress testing before launch?
When peak demand is not supported by evidence, or overload could cause material business loss, run performance tests proportionate to the risk before launch. The goal is not an impressive QPS number. It is to prove core-flow success and response at target load, identify the first limiting resource, and confirm controlled rejection and recovery beyond the limit. Wavesteam derives the depth from the real workload, not a universal user or device threshold.
Functional tests usually send a few sequential requests. Production creates concurrent writes, locks, exhausted pools, cold caches, queue growth, retry amplification, and supplier limits. A fast endpoint does not prove that login, search, order, and payment callback work together. Code, data, indexes, dependencies, and resources change, so an old report cannot permanently certify a new release.
When planning milestones, resources, and acceptance, also compare What should a useful load-test report measure? and Why start with a demo, and what should it prove?; the linked guidance adds context that should be considered in the same decision.
| Test | Question | Load pattern | It does not replace |
|---|---|---|---|
| Baseline or load | Does target business volume meet the objective? | Realistic mix rising to target | Limit and long stability |
| Stress or limit | Where is the inflection and how does overload fail? | Increase beyond threshold | Sudden spike and complete recovery |
| Spike | Do queue, scaling, and limits handle abrupt traffic? | Sharp rise and fall | Long-term leak |
| Soak | Do memory, connections, queues, or data degrade over time? | Sustained medium-high load | Sudden peak |
| Fault under load | Does a slow dependency or failed node cascade? | Load plus latency, disconnect, or quota | Full disaster-recovery exercise |
Google SRE's production service practices and cascading failure guidance connect load testing to capacity and overload behavior, including gradual and sudden demand. They do not prescribe one concurrency number.
Convert forecasts or logs into executable scenarios: operation mix, arrival or concurrency, think time, payload, data cardinality, connections, batches, and scheduled jobs. Transactions include creation, query, cancellation, and callback. IoT includes connection, heartbeat, telemetry, command, and reconnect storm. Content includes upload bandwidth, processing, and reads.
Document production differences in instances, network, database volume, cache, and whether external services are real or simulated. Never load production or a supplier without authority. Use sandboxes or controlled stubs for messaging, payment, and maps with real contract behavior tested separately.
Set pass and stop conditions before execution: business success, P95/P99 response, queue ceiling, and recovery. Grafana k6's metrics documentation provides request, failure, latency, and thresholds as tools, but its example numbers are not a project SLA.
A low-frequency internal tool with evidenced use and headroom may need only a light baseline and key-query test. Mature SaaS capacity should be checked through the supplier SLA, limits, and the client's integration. Marketing, transactions, device control, imports, video, real-time work, and explicit SLAs normally need peak, overload, and recovery coverage.
After fixing a bottleneck, rerun the same model and retain scripts, versions, configuration, raw results, and monitoring timeline. Wavesteam treats “the target scenario passes and failure is controlled” as launch evidence, not a fixed number of consulting days or one dashboard screenshot.