We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Messaging Event Systems
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Messaging Event Systems
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You send a postcard from vacation. No registered mail, no tracking, no delivery confirmation. Either it arrives or it doesn't. If it gets lost, you'll never know, and you won't send it again because you don't even realize it's missing.
That's at-most-once delivery. The message is sent exactly once. If the delivery fails (network drops, the consumer crashes, the broker loses the message), nobody retries. The message is gone.
This sounds terrifying. And for bank transactions, it is. But for many types of data, at-most-once is not just acceptable, it's preferred. Sensor readings arrive every second; missing one is irrelevant because the next one arrives a moment later. Metrics flowing to your monitoring dashboard: losing one data point in a thousand doesn't affect the graph. Video game position updates: if a packet drops, the next update corrects the position 16ms later.
At-most-once is the fastest and simplest delivery guarantee because it skips all the machinery that makes retries and deduplication possible. No acknowledgment tracking, no persistent storage of in-flight messages, no redelivery timers. Send and forget.
At-most-once happens when the system acknowledges the message before confirming processing:
Scenario 1: Pre-acknowledgment. The consumer receives the message, sends an ACK to the broker, and then starts processing. If the consumer crashes during processing, the message is lost. The broker already considers it delivered.
Broker ──[msg]──> Consumer
Consumer ──[ACK]──> Broker "Got it, don't resend"
Consumer starts processing...
Consumer CRASHES! Message is lost forever
Scenario 2: Fire-and-forget over UDP. The sender transmits the message and moves on. No ACK is expected. If the network drops the packet, nobody knows. StatsD metrics work this way: the agent sends a UDP datagram and never checks if it arrived.
Scenario 3: Auto-ACK mode in queues.
RabbitMQ's autoAck: true mode delivers the message and immediately removes it from the queue. If the consumer can't process it, it's gone. No retry, no dead letter, nothing.
Where at-most-once lives in practice:
| System | Setting | Effect |
|---|---|---|
acks=0 (producer) | Broker doesn't confirm receipt. Producer writes blind. | |
| RabbitMQ | autoAck: true | Message removed on delivery, not on processing |
| MQTT | QoS 0 | Fire and forget. IoT sensors use this heavily. |
| UDP | Inherent | No delivery guarantee at the transport layer |
| Pub/Sub | Inherent | If no subscriber is listening, message vanishes |