Computer & IT
API Throughput Capacity Calculator
Convert worker count and per-worker throughput into raw, available, and safe request capacity, buffer peak demand, estimate concurrency from service time, and calculate the whole workers and monthly cost required.
Raw rated throughput per second-
Availability-adjusted throughput-
Safe throughput at utilization ceiling-
Peak demand including growth buffer-
Safe capacity minus design demand-
Exact workers required before rounding-
Whole workers required for design demand-
Estimated concurrent work in process-
Peak demand utilization of safe capacity-
Current monthly worker cost-
Required monthly worker cost-
Decision view
API Throughput Capacity capacity envelope
API Throughput Capacity capacity envelopeRaw capacity is adjusted for availability and utilization, then compared with buffered design demand, required workers, concurrency and monthly cost.
Exact scenario comparisonPeak requests per second changes while all other entered assumptions remain constant.
| Peak requests per second | Raw rated throughput per second | Availability-adjusted throughput | Safe throughput at utilization ceiling | Peak demand including growth buffer | Safe capacity minus design demand | Exact workers required before rounding | Whole workers required for design demand | Estimated concurrent work in process | Peak demand utilization of safe capacity | Current monthly worker cost | Required monthly worker cost |
|---|
How to use API Throughput Capacity Calculator
- Measure sustained throughput and latency for the real endpoint mix, payload sizes, and dependency behavior.
- Choose a utilization ceiling that leaves room for bursts, garbage collection, retries, deploys, and node loss.
- Load-test the proposed worker count and verify database, cache, queue, network, and rate-limit behavior.
Calculator guide
Understanding API Throughput Capacity Calculator
API capacity planning must distinguish request throughput, service latency, concurrent work, availability-adjusted capacity, and the utilization headroom reserved for bursts and failures.
Calculation method
How the calculation works
Translate API request demand, service time, worker count, per-worker rate, utilization ceiling, availability and growth buffer into safe capacity, required workers, concurrency, headroom, and monthly infrastructure cost. Multiply worker count by rated requests per second, apply availability and utilization ceilings, increase peak demand by the growth buffer, and use rate multiplied by service time to estimate concurrent work.
Systems model
Separate throughput, latency, concurrency, and availability
These four measures answer different capacity questions and should be tested independently.
Worked situations
Practical examples
- A service sustaining 100 requests per second at 200 ms average service time carries about 20 requests in process.
- Ten workers rated at 50 requests per second do not provide 500 safe requests per second after availability and headroom.
- A positive average margin can coexist with poor tail latency during short bursts.
Better inputs
Useful tips
- Plan with p95 or p99 latency and a representative endpoint mix.
- Separate stateless compute from database connections, queue consumers, and external API quotas.
- Test one-node failure and rolling deployment capacity.
Before relying on the result
Limitations and common mistakes
- Average service time does not reproduce queue distributions, tail latency, burst correlation, cold starts, or retry storms.
- Per-worker throughput may not scale linearly because of shared dependencies.
- Cost excludes databases, caches, egress, observability, licenses, and standby regions unless embedded in the worker cost.
Reference
Key terms
- Throughput
- Completed requests per unit time.
- Service time
- Processing time used in the concurrency approximation.
- Safe capacity
- Availability-adjusted capacity constrained by the utilization limit.
- Capacity margin
- Safe capacity minus buffered design demand.
Important note
Calculated from the entered technical values using the displayed model. Validate topology, workloads, capacity, security, redundancy, and observed performance before implementation.
Frequently asked questions
Why use a utilization limit below 100%?
Queue delay rises sharply near saturation and the service needs failure and burst headroom.
Does average latency predict p99 latency?
No.
Why can adding workers stop helping?
A shared database, queue, lock, network path, or external quota may become the bottleneck.
Should required workers be rounded upward?
Yes, deployable worker count is discrete.