What does at-least-once delivery mean, and can you get exactly-once?
At-least-once means a message is never lost but may be delivered more than once. True exactly-once delivery is not practical across a network, so systems use at-least-once plus idempotent consumers to get exactly-once effects.
Explain it simply
A consumer processes a message and then sends an acknowledgement (ack). If the ack gets lost, the broker thinks the message failed and sends it again. To never lose a message you accept possible duplicates.
Delivery guarantees:
- At-most-once: send once, never retry. No duplicates, but messages can be lost.
- At-least-once: retry until acked. No loss, possible duplicates. The usual default.
- Exactly-once: each message affects the outcome once. Delivery itself cannot guarantee this, because the sender can never be sure whether a lost ack means the work happened or not.
The practical answer is effectively-once: deliver at least once, and make processing idempotent. Store a message id and skip ids already processed, or use operations that are safe to repeat ("set status to paid", not "add 100").
Some platforms advertise exactly-once within their own boundary, for example Kafka transactions between topics, but side effects outside it still need idempotency.
Example
Payment-credited message delivered twice:
msg {id: 77, credit: 500}
First delivery : id 77 not seen -> credit 500, record 77
Second delivery: id 77 already recorded -> skip
Balance increased by 500 onceWhat to say in the interview
"Exactly-once delivery isn't truly achievable over an unreliable network. I use at-least-once delivery and make consumers idempotent with a message id or a naturally repeat-safe operation, which gives exactly-once effects."