At-Least-Once Delivery
A messaging guarantee where every message is delivered one or more times. Simpler than exactly-once but requires consumers to handle duplicates via idempotency.
What is At-Least-Once Delivery?
In short
At-least-once delivery is a messaging guarantee where every message is delivered to its consumer one or more times, never zero. The broker keeps re-sending a message until it gets an acknowledgment, so duplicates are possible and consumers must handle them, usually by making their processing idempotent.
What it actually means
Message systems offer three delivery guarantees: at-most-once (a message may be lost but is never duplicated), at-least-once (a message is never lost but may be duplicated), and exactly-once (delivered once, no loss, no duplicate). At-least-once sits in the middle and is the default for most production systems because losing a message is usually worse than seeing it twice.
The contract is simple. The broker holds onto a message until the consumer confirms it finished processing. If that confirmation never arrives, the broker assumes the message was not handled and sends it again. That single rule, retry until acknowledged, is what produces the guarantee and also what produces the duplicates.
The duplicates are not a bug. They are the price you pay for not losing data. A consumer can process a message, crash before it sends the acknowledgment, and the broker will redeliver the same message to a different consumer. From the consumer's side, it just received the message twice.
How it works under the hood
The mechanism is an acknowledgment plus a redelivery timer. When a consumer pulls a message, the broker marks it as in-flight and starts a clock (in Amazon SQS this is the visibility timeout, default 30 seconds). The message is hidden from other consumers during that window.
If the consumer sends an ack before the timer expires, the broker deletes the message and moves on. If the consumer crashes, times out, or the ack is lost on the network, the timer fires, the message becomes visible again, and another consumer picks it up. Kafka does the equivalent with consumer offset commits: the message is reprocessed if the offset was not committed before a rebalance or crash.
Duplicates also come from the producer side. A producer sends a message, the broker stores it, but the broker's success response is lost in transit. The producer assumes failure and resends, so now two copies exist. This is why at-least-once duplication can happen even when every consumer behaves perfectly.
The standard defense is idempotency on the consumer. You attach a unique message ID or business key, record processed IDs in a database or cache, and skip anything you have already seen. Operations that are naturally idempotent, like setting a value rather than incrementing it, need no extra bookkeeping at all.
When to use it and the trade-offs
Use at-least-once when correctness depends on every event being processed and you can tolerate or deduplicate repeats. Order processing, payment events, audit logs, and email queues all fit, as long as the consumer is idempotent. It is the right default for the large majority of event-driven systems.
Avoid it, or add deduplication, when a duplicate causes real damage. Charging a credit card twice, sending two confirmation emails, or double-incrementing a counter are the classic failure modes. The framework guarantees delivery; it does not guarantee your handler is safe to run twice.
The trade-off against exactly-once is cost and complexity. True exactly-once requires coordination, transactions, or deduplication state, which adds latency and moving parts. At-least-once is cheaper, faster, and easier to reason about, and in practice most exactly-once systems are at-least-once delivery plus idempotent processing wearing a nicer label.
Where it is used in production
Amazon SQS
Standard queues guarantee at-least-once delivery; the visibility timeout hides an in-flight message and redelivers it if no acknowledgment arrives.
Apache Kafka
The default consumer setup is at-least-once: a crash or rebalance before the offset is committed causes records to be reprocessed.
RabbitMQ
With manual consumer acknowledgments, an unacked message is requeued and redelivered, giving at-least-once semantics.
Stripe
Sends webhook events with at-least-once delivery and a stable event ID, and tells integrators to dedupe on that ID to stay idempotent.
Frequently asked questions
- What is the difference between at-least-once and exactly-once delivery?
- At-least-once means a message is never lost but may arrive more than once, so consumers must handle duplicates. Exactly-once means each message is processed once with no loss and no duplicates, which needs extra coordination or deduplication. Most real exactly-once systems are at-least-once delivery combined with idempotent consumers.
- Why do duplicates happen with at-least-once delivery?
- A message is redelivered whenever the broker does not receive an acknowledgment in time. That happens if the consumer crashes after processing but before acking, if the ack is lost on the network, or if a producer resends because the broker's success response went missing. The broker retries to avoid loss, and retrying is what creates the duplicate.
- How do I handle duplicates in an at-least-once system?
- Make your consumer idempotent. Give each message a unique ID, store the IDs you have already processed in a database or cache, and skip any ID you have seen before. Where possible, design operations so running them twice has the same effect as running them once, such as setting a value instead of incrementing it.
- Is at-least-once delivery the same as guaranteed delivery?
- Roughly yes. At-least-once is the common meaning of guaranteed delivery: the system promises the message will reach the consumer, retrying until it is acknowledged. The catch it adds is that the guarantee comes with possible duplicates, which at-most-once avoids by accepting occasional loss instead.
- Does at-least-once delivery guarantee message ordering?
- No. Delivery and ordering are separate guarantees. A redelivered message can arrive out of order relative to later messages, so if you need order you must use an ordered partition or queue, such as a Kafka partition or an SQS FIFO queue, in addition to the delivery guarantee.
Learn At-Least-Once Delivery hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
Exactly-Once Processing
A processing guarantee where each message is processed exactly one time, even in the face of failures. Achieved through idempotent consumers and transactional producers.
Idempotency
An operation that produces the same result whether you run it once or multiple times. Critical for safe retries in distributed systems.
Message Queue
A buffer that stores messages between producers and consumers. Messages are processed one by one, in order. Think of it as a to-do list for your services.
Pub/Sub
A messaging pattern where publishers send messages to topics, and subscribers receive messages from topics they care about. Publishers don't know who's listening.
Kafka
A distributed event streaming platform that handles millions of events per second. Used by LinkedIn, Netflix, and Uber for real-time data pipelines.
Webhook
An HTTP callback triggered by an event. Instead of polling for updates, the source system pushes a notification to your URL when something happens.