Delivery guarantees

A delivery guarantee says how many times a message can reach its consumer. With at-least-once delivery, a job that gets no acknowledgment within the 30 s visibility timeout goes out again. So the consumer must handle the same job twice.

Play a level

See it on the board

The same traffic runs on two boards. The simulator measured both when this page was built.

Board to show
AMQPHTTP/2UsersMessage bro…1 vCPU · 1 GBPayment pro…2 vCPU · 2 GB
AMQPHTTP/2UsersMessage bro…1 vCPU · 1 GBPayment pro…2 vCPU · 2 GB
Payment runs again on each repeated delivery: misses a goal
AMQPHTTP/2UsersMessage bro…1 vCPU · 1 GBPayment pro…2 vCPU · 2 GB
AMQPHTTP/2UsersMessage bro…1 vCPU · 1 GBPayment pro…2 vCPU · 2 GB
Payment provider checks an idempotency key: meets the goals
See it on the board
Measure Goal Payment runs again on each repeated delivery Payment provider checks an idempotency key
Duplicates none 200 Fail 0 Pass
Completion time under 40 s 10.1 s Pass 10.1 s Pass
Lost writes none 0 Pass 0 Pass
Monthly cost 12 USD/mo 12 USD/mo
Error rate 0% 0%

Key numbers

Default queue settings and part values from the catalog. The simulator uses the same values.
NumberValue
Time before an unacknowledged job goes out again30 s
Deliveries of one job before it stops, default5 deliveries
Jobs one consumer can hold at once, default20 jobs
Call to the payment provider, median150 ms
Delivered twice, charged onceTap to turn the ID check on or off

13 deliveries · 10 payments applied · 0 charged twice

How it works

A queue and its consumer agree on delivery through acknowledgments. The consumer takes a job, does the work, then sends an ack. Only then does the queue delete the job.

The order of these steps sets the guarantee. At most once: the queue deletes the job when it sends it. A crash in the consumer loses the job, but the job never runs twice. At least once: the queue keeps the job until the ack arrives. If the consumer crashes, the ack is lost, or the work takes longer than the visibility timeout, the queue sends the job again. No job is lost, but some jobs run twice.

Exactly once is not a property of the network. You get its effect when at-least-once delivery meets a consumer that ignores repeats, for example with an idempotency key that it stores with the result.

A limit on deliveries protects the system from a job that always fails. After the last try, the queue moves the job to a dead letter queue, where a person or a tool can examine it. Without that limit, one bad job can block a consumer forever.

In the levels you choose the delivery mode, set the timeouts and make repeated jobs safe.