← All calculators
Latency budget planner
Build a request path from network hops, disk reads, caches and queries, group calls in sequence or in parallel, and see what is left of a p99 target.
Request path
p99 ÷ typical for the whole path; 1 if you entered p99s
Stages run one after another. Inside a stage, steps run in sequence or in parallel; a parallel stage costs as much as its slowest branch, and a count repeats that call in series.
Stage 11 ms typical
Same-AZ RPC
Redis GET (same AZ)
Stage 24 ms typical
Postgres indexed query
Cross-AZ RPC
Stage 370 ms typical
Cross-region round trip
Budget
- Estimated p99
- 113 mstypical 75 ms × 1.5
- Left in budget
- 87.5 mstarget 200 ms
- Stage 1 · sequential1.5 ms
- Stage 2 · parallel6 ms
- Stage 3 · sequential105 ms
- Left87.5 ms
How this is calculated
- A step
step = latency per call × count- A stage
- Sequential:
sum of steps. Parallel:max of steps, because you wait for the slowest branch. - The path
typical = sum of stagesandp99 ≈ typical × tail factor. Percentiles don’t add exactly, so treat this as a sanity check, not a promise.- Presets
- Round, typical figures inside one cloud region. Edit any number to match what you have measured.
What to say in the interview
- “I’ll budget the request: at typical latencies this path is about 75 ms, and allowing 1.5× for the tail that’s roughly 113 ms at p99 against a 200 ms target, which leaves 87.5 ms of headroom.”
- “The biggest slice is stage 3, at about 105 ms, so that’s where I’d look first: cache it, run it in parallel, or move it off the request path.”
- “A synchronous cross-region round trip costs tens of milliseconds by itself, so I’d only keep it for writes that genuinely need cross-region durability; everything else replicates asynchronously.”