Delivery guarantees: at most, at least, exactly once
A queue promises to lose some messages, to repeat some, or to do neither. What decides which one you get, where do repeats come from, and what does "exactly once" really buy?
13 minMediumStation: Delivery guarantees: at most, at least, exactly onceMembers lesson
Membership isn’t open yet. The free lessons are open — 17 of them.
- Pub/sub fan-out
- Notify’s big night
- Delivery guarantees: at most, at least, exactly once
- Idempotent consumer
- Poison messages & dead-letter queues
What you'll be able to do
- 1Explain at-most-once, at-least-once and exactly-once by when the consumer confirms a message relative to doing the work, and what each one loses or repeats when a worker fails.
- 2Predict where duplicate deliveries come from and how many reach downstream — a lost confirm, a worker crash after the work, a hiding timeout shorter than the work, a producer resending after an unclear answer.
- 3Choose a guarantee for a job from what losing it or doing it twice would cost, and read a broker's "exactly-once" feature for what it covers — the queue, not the consumer's side effects.
Inside the lesson
- steps
- 12
- questions
- 9
- simulations
- 4
You guess first, then run the system and see if you were right.
Step 1 · The setup
After the big night every one of Notify's pushes gets through. Then the support tickets start: "I got 'Your order shipped' twice."
Notify's three senders share the send queue as competing consumers. A sender confirms — reports done — a notification only once the push provider accepts it, and one it never confirms comes back to the queue. That's how nothing got lost when a sender crashed at the competing-consumers stop, and also why about 400 of its pushes went out twice.
An engineer proposes a fix: confirm each notification the moment a sender takes it. Once confirmed, the queue forgets it — so it can't come round again.
Steps 2–12 are for members