You've been asked to set the performance acceptance criteria for a new checkout API before it ships. How do you decide what numbers to commit to and how to load-test against them, rather than just picking a round latency target out of the air?

technical-conceptual · Senior level · software-engineering

What the interviewer is really asking

Assesses whether the candidate can derive performance targets from real demand and business impact (percentile latency at a projected arrival rate) and design a representative test, instead of asserting an arbitrary threshold disconnected from production traffic.

What to say

• Derive targets from demand, not vibes: start from projected and peak traffic (requests/sec, including spike events), the latency the user experience and downstream timeouts can tolerate, and express the SLO as a percentile-at-load, e.g. p99 under X ms at Y requests/sec, plus an error-rate ceiling.
• Make the test representative: model a realistic traffic mix and think-time, use production-shaped data volumes, warm caches as production would be, and inject load at the target arrival rate (open model) so you measure the system as users will actually hit it.
• Define ramp, soak, and failure behavior: test at peak and a stress multiple beyond it to find the knee, run a soak to catch leaks and degradation over time, and decide pass/fail on the committed percentile and error budget — not the average and not a single happy-path run.

What to avoid

• Committing to a round number like 'sub-200ms' with no link to actual traffic, user tolerance, or downstream timeout budgets.
• Testing only the average response time or a single concurrency level instead of percentile latency across realistic and peak load.
• Skipping soak and stress runs, so leaks and the saturation point go undiscovered until production.

Example answers

Strong: I'd anchor the targets in demand and impact: pull projected and peak requests/sec, find the latency the checkout flow and its downstream timeouts can tolerate, and commit to a percentile-at-load SLO like p99 under 300ms at peak rps with an error rate under 0.1%. Then I'd test it representatively — realistic endpoint mix, production-sized data, open-model injection at the target arrival rate — and run ramp, peak, a stress multiple to find the knee, and a soak for leaks. Pass/fail is the committed percentile and error budget, not the average or one clean run.

Weak: I'd target sub-200ms response time since that's the standard for a good API, then run a load test ramping up users until the average response time crosses 200ms and call that the limit.