A queue buys time. It does not create processing capacity.

Model one queue before adding more workers

Imagine a background pipeline that normally receives 100 jobs per second. Its workers can finish 150 jobs per second. A launch causes arrivals to jump to 300 jobs per second for four seconds, after which they return to 100. Assume the queue starts empty and every job takes the same average amount of work.

During the burst, incoming work exceeds capacity by 150 jobs per second. Over four seconds, the backlog grows to 600 jobs. That is the buffer requirement in an ideal continuous-flow model with no retries or overhead. Real systems need additional margin for variability and discrete arrivals.

Calculate the recovery, not just the burst

After the burst, workers finish 150 jobs per second while another 100 arrive. The spare capacity is 50 jobs per second. Draining 600 jobs therefore takes 12 seconds. If normal arrivals were also 150, there would be no spare capacity and the backlog would not drain. A system can remain technically running while its delay never recovers.

burst_backlog = (burst_arrivals - service_rate) × burst_duration
             = (300 - 150) × 4 = 600 jobs

spare_capacity = service_rate - normal_arrivals = 50 jobs/s
drain_time = backlog / spare_capacity = 600 / 50 = 12 s

These equations describe work conservation. They do not predict exact per-job wait times or a percentile. For that, consider arrival variability, service-time distributions, priorities and how consumers schedule work.

What happens with a smaller buffer?

If only 400 jobs can wait, the ideal model overflows by 200 jobs during this burst. You must decide what overflow means. Rejecting new work, shedding lower-priority jobs and applying producer backpressure are different product behaviors. Silently dropping jobs is a poor default for orders or payments. Retrying without a bound can turn rejection into a larger traffic storm.

A queue also cannot make a slow downstream dependency faster. If a worker dequeues a job and then fails to write its result, dispatch is not completion. Track queued, in-flight, completed and failed work separately. A chart that counts every dequeue as a successful job can look healthy while losing real outcomes.

Add delivery semantics deliberately

A real messaging service may redeliver work. Give important operations stable business identifiers and make repeated processing safe. Define retry limits, a dead-letter path, visibility or lease behavior, and a way for operators to inspect failures. A teaching buffer does not implement those guarantees just because its component is named after a messaging product.

Start monitoring oldest-job age as well as queue length. Ten slow expensive jobs can be more urgent than a thousand cheap ones. Test worker restarts, a downstream outage and recovery at realistic traffic. Then change one parameter at a time: capacity, buffer size or admission policy. You should be able to explain where every admitted job went.