advanced

Load testing

Model traffic, ramp-up, steady load, spike behavior, failure limits, and bottlenecks before relying on capacity assumptions.

Load testing models traffic against a system to find capacity limits, saturation points, and failure modes before production proves them. Tools include k6, Gatling, Locust, and JMeter.

| Phase | Goal | |-------|------| | Smoke | Low VUs verify script works | | Load | Expected steady traffic | | Stress | Increase until errors or SLA break | | Spike | Sudden jump tests autoscale/backpressure | | Soak | Hours-long run finds leaks |

					// k6 sketch
export const options = { stages: [
  { duration: '2m', target: 100 },
  { duration: '5m', target: 100 },
  { duration: '2m', target: 0 },
]};
				

Define **success criteria**: p95 latency, error rate, queue lag, CPU. Use realistic payload sizes and think time. Test from near production topology—isolated microservice tests miss integration bottlenecks.

On interviews: open vs closed workload models; coordinated omission in tools; why soak tests matter; safe load test environments.

Common pitfalls: testing prod without isolation; unrealistic 0ms think time; ignoring downstream third-party rate limits.

The trade-off is confidence in capacity versus cost and risk of testing shared environments.

Checklist:

  • Script realistic user journeys.
  • Ramp gradually; watch saturation metrics.
  • Never load-test prod without safeguards.
  • Document max sustainable RPS found.