We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Messaging & Event Systems
A messaging guarantee where every message is delivered one or more times. Simpler than exactly-once but requires consumers to handle duplicates via idempotency.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers At-Least-Once Delivery across a run of lessons, not one page. These 4 alone are about 74 minutes of step-by-step reading, every one with a quiz.
Never lose a message, but you might see it twice.
Design consumers that produce the same result whether a message is processed once or ten times.
Scale message processing by having multiple consumers race to handle messages from the same queue.
Let consumers receive only the messages they care about, filter at the broker, not in code.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with At-Least-Once Deliverypay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This page explains the idea. The "At-Least-Once Delivery" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the At-Least-Once Delivery lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about At-Least-Once Delivery in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
