This estimator calculates fraud-detection transaction throughput from parallel workers, per-worker processing time, and availability. It also compares effective capacity with a target demand level and reports utilization at that target.
Use it to evaluate whether an existing deployment can sustain expected traffic or to compare optimizations such as faster inference and additional workers. The model is deliberately simple, making its assumptions visible before more detailed queueing or load-test analysis.
1. Enter parallel capacity
Count independent workers or request slots that can process transactions simultaneously.
2. Enter measured processing time
Use the end-to-end time for one transaction under representative load.
3. Adjust for availability
Account for downtime, maintenance, throttling, or other capacity losses.
4. Compare with demand
Enter the target transaction rate and review the resulting utilization percentage.
Raw throughput = Parallel workers ÷ Processing time in seconds
Effective throughput = Raw throughput × Availability %
Utilization at target = Target TPS ÷ Effective TPS × 100
The main result is the estimated sustained transaction rate after the availability adjustment.
At high utilization, queueing can increase latency before the theoretical throughput limit is reached.
Given: 24 workers, 140 ms per transaction, 95% effective availability, and a target of 140 TPS.
Calculation: Raw throughput = 24 ÷ 0.140 = 171.43 TPS. Effective throughput = 171.43 × 0.95 = 162.86 TPS. Utilization = 140 ÷ 162.86 × 100 = 85.96%.
Result: Estimated effective throughput is 162.86 TPS.
Only if each worker handles one transaction at a time. Async execution, batching, or internal parallelism can change the relationship.
It provides a simple way to reduce ideal capacity for downtime, throttling, and other losses observed in production.
There is no universal threshold. Use load tests and latency objectives to determine how much headroom your system requires.
Yes, for a conservative estimate, but the result then represents capacity under that slower processing assumption rather than average throughput.
This tool starts from available workers to estimate throughput; the latency capacity estimator starts from required traffic to estimate concurrency.