Latency Budget
Free Latency Budget calculator with clear step-by-step results.
About Latency Budget
Decomposes a latency target into the parts you cannot change and the part you can. Network round trip and per-hop overhead are structural, database time scales with call count, and what remains is the compute budget every service in the chain has to share - which is often alarmingly small.
Formulas
Consumed budget
Consumed = network RTT + hops x per-hop overhead + queries x per-query latency
Remaining compute
Remaining = target p99 - consumed
Worked example
With the default values below, Latency Budget returns Budget left for application compute of 236.00. Change any input above and every figure here is recalculated in your browser.
Inputs used
- End-to-end p99 targetminimum 1 ms
- 400 ms
- Network round tripminimum 0 ms
- 60 ms
- Internal service hopsaccepts 1–40
- 4
- Fixed overhead per hopminimum 0 ms
- 8 ms
- Database calls per requestminimum 0
- 6
- Latency per database callminimum 0 ms
- 12 ms
Results
- Budget left for application compute
- 236.00 ms
- Network and hop overhead
- 92.00 ms
- Time spent in the database
- 72.00 ms
- Share of the target already consumed
- 41.0% %
Step by step
- 1Values used
- 2Consumed budget
- 3Remaining compute
- 4Budget left for application compute= 236.00 ms
- 5Network and hop overhead= 92.00 ms
- 6Time spent in the database= 72.00 ms
- 7Share of the target already consumed= 41.0 %
Assumptions and limits
- The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
What if the remaining budget is negative?
The target is unreachable with this architecture. The usual fixes are cutting service hops, batching or caching database calls, or moving compute closer to the user.
Why does query count matter more than query speed?
Because they multiply. Six calls at 12 ms is 72 ms; batching them into one round trip typically costs 15-20 ms total, which is often the single largest available saving.