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 9-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”
Imagine a courier who delivers a package and waits for you to sign. If you don't answer the door, they come back tomorrow. And the next day. And the next. They will not stop until you sign for the package.
But what if you signed, and the courier's system glitched and lost the signature? They'll come back again. Now you have two packages.
That's at-least-once delivery. The system guarantees your message will be delivered, even if the consumer crashes, the network blips, or the broker restarts. The price: the message might arrive more than once. Duplicates are possible, and the consumer must handle them.
At-least-once is the most common delivery guarantee in production messaging systems. , RabbitMQ (with manual ACK), SQS, Google Pub/Sub: they all default to at-least-once. The reason is pragmatic. Losing messages is almost always worse than receiving duplicates. You can handle duplicates with idempotency. You can't recover data you never received.
At-least-once works by flipping the acknowledgment order from at-most-once:
At-most-once: ACK first, process second. If processing fails, message is lost. At-least-once: Process first, ACK second. If ACK fails, message is redelivered.
Broker ──[msg]──> Consumer
Consumer processes the message...
Consumer ──[ACK]──> Broker "Done processing, remove it"
If the consumer crashes after processing but before sending the ACK, the broker doesn't know the message was handled. When the consumer restarts, the broker redelivers the message. The consumer processes it again: a duplicate.
Duplicate scenarios:
The common thread: any failure between "message received" and "ACK confirmed by broker" results in redelivery.
Settings that enable at-least-once:
| System | Setting | Visibility window |
|---|---|---|
enable.auto.commit=false + manual commit after processing | Offset not committed until you say so | |
| RabbitMQ | autoAck: false + channel.ack(msg) after processing | Message stays in queue until ACK |
| SQS | Visibility timeout (default 30s) + explicit delete | Message reappears after timeout if not deleted |
| Google Pub/Sub | Manual acknowledgment + ack deadline (default 10s) | Redelivered if not acked within deadline |