Queue Throughput Sizing Calculator

Work out queue throughput sizing instantly with clear inputs, formula shown and shareable results.

About Queue Throughput Sizing Calculator

Messages in flight follow Little's law — arrival rate times processing time — and consumer count is that divided by per-consumer concurrency. The visibility timeout must comfortably exceed processing time, ideally by three times or more, because a message whose timeout expires mid-processing is redelivered and processed twice.

Formula

Queue sizing

in flight = message rate x processing time; consumers = ceil(in flight / concurrency per consumer); visibility timeout should exceed 3x processing time

Worked example

With the default values below, Queue Throughput Sizing Calculator returns Consumers required of 125. Change any input above and every figure here is recalculated in your browser.

Inputs used

Messages per secondminimum 0.001: 5,000
Processing time per messageminimum 0 s: 0.25 s
Concurrent messages per consumerminimum 1: 10
Visibility timeoutminimum 0.001 s: 30 s

Results

Consumers required: 125
Messages in flight: 1,250.0
Visibility timeout as a multiple of processing time: 120.0 x
Timeout assessment: Visibility timeout gives adequate margin

Step by step

1Values used
2Queue sizing
3Consumers required= 125
4Messages in flight= 1,250.0
5Visibility timeout as a multiple of processing time= 120.0 x
6Timeout assessment= Visibility timeout gives adequate margin

Assumptions and limits

The result is derived only from the 4 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 1 decimal place, 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 happens if the visibility timeout is too short?

The message becomes visible again while still being processed, so another consumer picks it up. Duplicate processing follows, which is why handlers must be idempotent.

Should the timeout just be set very long?

No. A long timeout delays retry after a genuine consumer crash, so a failed message sits invisible for that whole period. Heartbeat extension is the better approach.