Ticket Presale: Stress Test or Something Else?
An online ticket seller expects a concert presale. Current baseline is 1,200 concurrent users during a normal sale, with 8% of sessions reaching checkout and an SLA of p95 response time under 3 seconds for checkout and under 1.5 seconds for search. Marketing forecasts 3,600 concurrent users at peak and a 10-minute surge to 6,000 users when the artist announces a bonus show. The system runs on Kubernetes with autoscaling from 6 to 20 pods and a fixed-size database. The product owner asks the performance team to 'run a stress test and tell us if we will survive.' The team has a four-hour test window and production-like test data, but the payment provider is a third-party sandbox with a 20 requests/second cap. No production load testing is allowed.
1. Which test types should the team design to answer the product owner's question, and what distinct question does each type answer? Justify the choice with the stated numbers and constraints.
Read the worked answer
A single test type cannot answer 'will we survive'. The team should select tests by objective:
- Load test at 3,600 concurrent users. This answers whether the forecast peak meets the SLA: checkout p95 < 3 s, search p95 < 1.5 s, acceptable error rate, and stable throughput. It is the primary acceptance test because 3,600 is the expected peak, not a failure probe.
- Stress test beyond 3,600. This finds the breaking point, the first bottleneck, and the failure mode. It answers 'where and how do we fail?' but not 'do we meet the SLA at forecast load'.
- Spike test to 6,000 for 10 minutes. This answers whether autoscaling and queueing absorb a sudden arrival-rate change. A slow ramp stress test would not reproduce the sudden surge or autoscaling lag.
- Capacity or scalability check across the 6-to-20 pod range. This answers how much headroom exists and whether the fixed database becomes the limiting tier before the pod limit.
Endurance testing is secondary in a four-hour window, but a shorter steady-state run at 3,600 could reveal early resource drift. The payment sandbox cap is a hard constraint: if the required authorization rate exceeds 20 requests/second, the team cannot validate end-to-end checkout throughput. Use service virtualization or a controlled stub for load and stress runs, then run a separate integration test at the cap. Report that limitation explicitly rather than extrapolating beyond the sandbox.
2. The product owner insists that a single stress test is enough: 'Just push it until it breaks and we will know.' Explain why this is insufficient, using at least two risks it leaves uncovered.
Read the worked answer
A stress test answers a different question from the one the business is asking. Pushing the system until it breaks can show the maximum concurrency and the failure mode, but it does not prove that the system meets the checkout p95 < 3 s and search p95 < 1.5 s at the forecast 3,600 users. A system can survive 8,000 users while returning pages in 20 seconds; that is a stress 'pass' with no business value.
Two risks left uncovered:
- SLA failure at expected load. The stress test may jump quickly through the 3,600-user range, so the team never holds steady state long enough to measure p95 and error rate under the forecast workload. The first bottleneck might be a batch job or cache expiry that only appears after sustained load.
- Spike behavior and autoscaling lag. A gradual stress ramp does not reproduce the sudden 6,000-user announcement surge. Kubernetes may take minutes to add pods; during that window, queues, timeouts, and errors can occur even if the eventual stress ceiling is high.
A third risk is ambiguous success: 'survive' may mean no crash, but the business needs acceptable response time, error rate, and recovery. The team should define measurable criteria for load, spike, and stress tests, and report the failure mode and recovery time from stress testing separately from SLA compliance at forecast load.
3. Define measurable exit criteria for the four-hour test window and explain how the third-party payment cap affects what can be concluded.
Read the worked answer
Exit criteria should be tied to each test objective, not to 'the test ran'.
Load test at 3,600 users: checkout p95 < 3 s; search p95 < 1.5 s; error rate below the agreed threshold, for example < 1%; throughput meets the forecast transaction rate; no pod restarts; CPU and memory below saturation thresholds; autoscaling completes within an agreed time, for example 2 minutes; database connections and queues remain stable.
Spike test to 6,000: no unrecovered errors after the surge; p95 returns to the load-test level within an agreed recovery window, for example 5 minutes; autoscaling responds without exhausting the database connection pool.
Stress test: identify the first bottleneck, the breaking point, the failure mode, and whether recovery is automatic. A stress test does not need a pass/fail SLA, but it must produce actionable evidence.
Payment cap: the 20 requests/second sandbox cap limits end-to-end payment authorization throughput. If the forecast requires more than 20 payment authorizations per second, the team can validate the application tier with a virtualized payment service, but cannot conclude that the real payment path will meet the SLA. The report must state the cap, the substitution used, and the residual risk. Do not present a stubbed run as proof of end-to-end payment capacity.