Load Testing

Why Production Finds It First

 untested capacity assumptions meet reality at the worst time:

 - black-friday traffic 3× forecast → checkout collapses
 - viral spike → connection pools exhaust invisibly
 - new feature's N+1 queries → DB melts under normal+10%

 LOAD TESTING converts unknown ceilings into MEASURED ones:

 [synthetic load ramp]──►[system]──observe──►[ceiling found]
   where does p99 break? which component saturates FIRST?

 capacity planning without load tests = folklore + hope.

The Test Menu

Type	Shape	Answers
baseline	expected peak replay	can we handle tomorrow?
ramp/step	increase until failure	WHERE is the ceiling?
soak	sustained moderate (hours-days)	leaks? degradation creep?
spike	sudden 0→peak	autoscaling + buffer behavior
stress	beyond expected extremes	failure MODES graceful?

 each answers a different question — teams default to
 baseline-only and stay blind to leak classes and
 scaling-latency gaps. rotate through the menu quarterly.

Making Load Tests Tell the Truth

 □ REALISTIC SHAPES: production request mixes, payload sizes,
   read/write ratios, user think-time — not 100% GET /health!
   replay/anonymized production traces are gold here.
 □ STATE realism: authenticated users with real session flows,
   cache states both cold and warm, data volumes AT PROD SCALE
   (a 1GB test DB hides every large-table behavior)
 □ ENVIRONMENT honesty: results only transfer from prod-like
   infra; note the deltas when impossible
 □ OBSERVE THE SYSTEM UNDER TEST: full dashboards during runs;
   the FINDING is usually WHICH dependency saturates first,
   not just aggregate RPS achieved
 □ ISOLATION: dedicated window; throttles to protect real users;
   never blind-fire at production (or do it carefully with
   read-only shadow paths)

Reading Results Like an Engineer

 the interesting outputs:

 - SATURATION ORDER: db pool → app CPU → LB limits...
   first bottleneck dictates scaling priorities ✓
 - KNEE POINTS: latency curves inflect BEFORE errors appear —
   find and respect the knee, not the cliff
 - SCALING LATENCY: spike tests reveal how LONG autoscaling
   takes to respond vs how fast traffic arrives (the gap =
   your shedding/buffer requirement)
 - DEGRADATION MODE: fail-fast errors or hang-forever?
   timeouts/breakers verified under genuine overload
 - POST-TEST RECOVERY: does it return to baseline cleanly,
   or limp (queue backlogs draining for hours)?

 every finding becomes either capacity work or resilience
 configuration — file findings like incidents.

Interview Framing

“Flash-sale event in 6 weeks; prove readiness” scored shape: multi-type plan (baseline+ramp+spike+soak), realistic-shape disciplines (prod traces, prod-scale data), saturation-order analysis as THE deliverable, scaling-latency gap tied to shedding strategy, isolation safety named. Load-testing questions test whether you measure systems as LIVING capacities rather than assuming diagrams hold at 10×.