Estimate endpoint latency from its downstream calls.
Estimated p50 latency
59 ms
Estimated p99 latency
273 ms
Needs roughly 137 concurrent in-flight requests to sustain that rate at p99 (Little’s Law: concurrency = rate × latency).
A first-order estimate. Real latency also depends on connection pools, queueing under load, retries, and network variance — validate with a load test before relying on these numbers.
List the downstream calls an endpoint makes — database queries, cache lookups, external APIs — with their p50 and p99 latencies, and this estimates the endpoint’s total latency. Run them sequentially and the latencies add up; run them in parallel and the request waits for the slowest one.
It also applies Little’s Law to estimate the concurrency you need: to sustain a target request rate, the number of in-flight requests is roughly rate × latency. Sizing against p99 rather than p50 keeps the pool from starving under the tail. These are first-order estimates — validate with a load test before relying on them.
Because averages hide the tail. Under load, the slow requests are the ones that pile up and exhaust your connection pool or thread pool. Sizing capacity against p99 (or higher) latency means the system stays healthy when a fraction of requests are slow, which is exactly when it matters.
By Little’s Law: the average number of in-flight requests equals arrival rate × average time in the system. So 500 req/s at 200 ms latency needs about 500 × 0.2 = 100 concurrent requests. This tool uses p99 latency to give a safety margin for the tail.