RabbitMQ / Basic: protocol resources, routing and ownership / Lesson 5

Prefetch, work and ordering

Bound outstanding deliveries and distinguish queue order from parallel business completion.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain prefetch scope and its memory/latency tradeoff.
Choose worker concurrency consistent with required key order.

Prefetch bounds deliveries awaiting acknowledgment

Consumer prefetch limits outstanding unacknowledged deliveries under the selected protocol and RabbitMQ interpretation. It is not the number of threads and does not automatically bound the bytes held by a worker. A hundred tiny messages differ from a hundred large documents. RabbitMQ commonly applies a non-global prefetch separately to each new consumer on a channel, which differs from the original AMQP 0-9-1 channel-oriented interpretation. Review exact scope and queue-type support rather than assuming one value caps the whole application. A prefetch count of zero means no limit in this context, not zero messages.

Count the application-wide exposure

The offline arithmetic assumes three consumers, each with a prefetch of eight, and a maximum synthetic body size of two thousand bytes. Twenty-four deliveries can be outstanding under those assumptions, with forty-eight thousand body bytes before client object overhead. The example does not predict RabbitMQ memory or exact in-flight frame behavior. Include headers, decoded objects and any downstream buffering in a real worker budget. Increasing prefetch can hide round-trip latency but also lets slow consumers hold more work and increases the amount replayed after failure. Measure a representative workload before choosing a larger window.

python Offline prefetch exposure estimate

consumers = 3
prefetch_each = 8
max_body_bytes = 2000
outstanding = consumers * prefetch_each
body_bytes = outstanding * max_body_bytes
assert outstanding == 24
assert body_bytes == 48000
print(outstanding, body_bytes)

Expected output

24 48000

The estimate counts bodies only and assumes the limit applies independently to each consumer.

Receiving in order does not mean finishing in order

A queue's delivery behavior does not guarantee external effects finish in that order when multiple consumers or concurrent handlers work independently. A slow earlier parcel update can finish after a fast later update and overwrite newer state. Redelivery and priorities can also affect observed order. If updates for one key require sequencing, design single-active-consumer behavior, key partitioning or destination version checks appropriate to the contract. A prefetch of one can reduce outstanding work but does not automatically establish a global causal order across publishers, queues or several active consumers.

Read a non-global consumer limit

The Java fragment requests a prefetch count before registering a consumer in the surrounding application. It omits connection and callback setup and is therefore non-runnable. The declared intent is a per-consumer bounded window with manual acknowledgment; automatic-ack behavior has a different safety and backpressure contract. Global channel QoS has queue-type and version limitations, so it is deliberately not used as a universal recipe here. The application still needs a bounded processing executor and a safe acknowledgment handoff. Moving every delivery into another unlimited local queue defeats the intended memory and completion budget.

java Illustrative per-consumer QoS fragment

channel.basicQos(8, false);

Apply through the chosen client’s documented registration lifecycle; no channel or consumer is created here.

Choose a window from evidence and failure cost

Compare completion throughput, end-to-end latency, unacknowledged count and worker memory together. A rising unacked count can mean slow work or missing acknowledgments rather than a broker delivery problem. More prefetch cannot repair a blocked destination and can make recovery heavier. Keep per-message work duration and size distributions alongside the selected setting. This lesson performs no benchmark, queue query or consumer registration. Its arithmetic checks declared capacity assumptions, while the actual client QoS operation and observed ordering remain untested platform behavior requiring an independently authorized compatible environment.

Common errors and fixes

Prefetch0 is expected to stop deliveries.

Why it happens: Zero was interpreted as an empty window instead of unlimited.
How to fix it: Use a positive reviewed limit for bounded outstanding work.
Prevent it next time: Test boundary settings against official client and broker semantics.

A small count still exhausts worker memory.

Why it happens: Body sizes and decoded-object overhead were omitted.
How to fix it: Budget bytes and downstream buffering as well as delivery count.
Prevent it next time: Measure representative size distributions.

Older state overwrites newer state after parallel processing.

Why it happens: Delivery order was confused with effect completion order.
How to fix it: Use an appropriate sequencing or destination-version rule.
Prevent it next time: Test overlapping updates to the same business key.

Check your understanding

1. Two consumers each receive a per-consumer limit of10. Is the whole application capped at10?

Show worked solution

Not under that declared per-consumer interpretation. Up to twenty outstanding deliveries can be exposed across the two consumers, subject to other constraints. Count all consumers and any additional local buffering, and distinguish a delivery-count budget from a byte budget or processing-thread limit.

2. Does prefetch1 guarantee ordered completion across two active consumers?