Load testing simulates concurrent user traffic against your system to measure how it performs under expected and worst-case volumes.
Load testing is the practice of driving synthetic traffic at your system to measure its behavior under load — latency curves, error rates, resource saturation points, and where things actually break. Done before big launches, capacity planning cycles, and enterprise deals promising specific performance, load testing is the difference between 'we think it'll scale' and 'we have measured it scaling.' The most common cause of Reddit-hug-of-death outages is skipped load testing.
(1) Load test — sustained expected traffic for 15-60 minutes; validates the system handles normal peak. (2) Stress test — traffic ramped past capacity to find the breaking point; reveals where the first bottleneck lies. (3) Spike test — sudden 5-10x traffic burst; simulates viral events and validates autoscaling reaction time. (4) Soak test — moderate load for many hours; catches memory leaks, connection exhaustion, and slow-growing problems that short tests miss. Most teams only run #1 and think they've load-tested. Real coverage requires all four, at least occasionally.
k6 (Grafana) — JavaScript-based test scripts, great DX, cloud or self-hosted execution, dominant new choice. Locust — Python-based, distributed by design, good for teams already in Python. Gatling — Scala-based, powerful reporting, more setup overhead. Artillery — Node.js, simple YAML tests. Cloud-hosted (k6 Cloud, BlazeMeter, Loader.io) removes the 'need to generate 100K RPS from your laptop' problem. For a typical SaaS team, k6 with cloud execution for large tests and local runs for iteration is the sweet spot.
The most common load-testing failure is testing the wrong workload — 100% GET /healthcheck at 10K RPS proves nothing about a real customer's mixed workload of logins, dashboard loads, and API calls. Build scenarios that mirror real user behavior: recorded traces from production traffic, weighted mixes of the top 10 endpoints, realistic think-time between actions, warm-up periods that populate caches. Test data must also be realistic — 100K test users with different roles and permissions, not 10 test users hammering the same endpoint (which quickly becomes a cache-hit test).
Response-side metrics: p50/p95/p99 latency per endpoint, error rate, throughput. System-side metrics from your APM/observability: CPU, memory, DB connections, queue depth, per-service latency. The disconnect between the two often reveals the bottleneck ('response latency spiked but our servers look idle → the DB or a downstream service is the ceiling'). Load tests without system-side observability are half-blind; you see the symptom without seeing the cause.
Two rhythms. (a) Pre-launch/pre-contract load tests — run before every launch that changes traffic patterns significantly or every enterprise deal that commits to specific SLAs. Bespoke, thorough, human-analyzed. (b) Continuous baseline tests — run a smaller load test nightly against staging, alert on regressions vs. last week's baseline. Catches gradual degradations before they compound. Both matter; teams that only do pre-launch tests miss slow regressions, teams that only do continuous baselines miss launch-specific failure modes.
Investor directory · Fundraising library · Articles A–Z · Company funding database