At-least-once delivery
A guarantee that a message will arrive, with no promise it arrives only once.
Most queues and webhook systems guarantee at-least-once delivery: if the consumer does not acknowledge, the message is redelivered. That makes duplicates normal rather than exceptional, so the consumer must be able to process the same message twice without doubling its effect. Exactly-once is rarely available and usually turns out to be at-least-once plus deduplication somewhere.
Full guide:
How many times a queue can deliver the same message
— There is no upper bound from the guarantee itself — at-least-once places no ceiling on repetition. The practical limit is the maximum receive count, after which the message goes to a dead letter queue, and that is typically set between three and five. Until that threshold, redelivery continues every time a consumer fails to acknowledge in time.
Key facts
- Duplicates are the expected case, not a fault: a consumer that breaks on redelivery is incorrect, not unlucky.
- Deduplication belongs in the consumer, keyed on a message id the producer supplies, because the transport cannot know what "the same" means to you.
- A message redelivered after a timeout may still be in flight in the first consumer, so processing must tolerate overlap as well as repetition.
- Ordering and at-least-once are separate guarantees: a redelivered message commonly arrives after messages that were produced later.
Frequently asked questions
How do I make a consumer idempotent?
Record the message id in the same transaction as the effect. On redelivery the insert conflicts and you skip the work. Checking a separate store first leaves a window where both attempts pass the check.
Is exactly-once delivery real?
Not end to end, in general. What is offered as exactly-once is normally at-least-once delivery combined with deduplication at the boundary — which is worth having, but it is worth knowing where the deduplication actually lives.
Machine-readable copy of this page:
/glossary/at-least-once-delivery.md