I'm reviewing message queue delivery semantics and got confused by a multiple-choice question asking which guarantees a queue system can provide:
- At-most-once: a message is delivered zero or one time, so it may be lost but should not be duplicated.
- At-least-once: a message is eventually delivered, but it may be delivered more than once.
- Exactly-once: each message is processed one time only, although this is difficult to guarantee in practice.
- Best-effort: the system attempts delivery without making a formal reliability guarantee.
I chose at-least-once and was marked wrong. I had assumed it was the only real guarantee because it's commonly documented, while exactly-once sounds impractical and at-most-once sounds like an undesirable failure mode. Are these all considered valid guarantees, depending on the queue's configuration and use case?
3 Answers
The likely intended answer is that a queue can support multiple delivery guarantees, depending on its settings and implementation. At-most-once, at-least-once, and sometimes exactly-once are all recognized semantics. Exactly-once usually has significant overhead and often describes the combined queue-and-consumer behavior, not merely removing a message from the queue once. So it is possible in some systems, but much harder to achieve end to end.
Best-effort can also be a real design choice, although it technically means there is no formal delivery guarantee. For example, a sensor system might drop queued readings when bandwidth is limited because approximate averages matter more than every individual data point. It may retry some messages and produce duplicates while still discarding others, so it does not fit neatly into at-most-once or at-least-once semantics. The exact answer depends on how strictly the question uses the word “guarantee.”
That is the important distinction: best-effort describes behavior without a promised delivery property. If the question expects only formal guarantees, it might exclude that option; if it asks what a queue system can be configured to do, it could be included.
At-most-once is absolutely a valid delivery guarantee. It means the consumer will not receive duplicates, but a message can be lost. That can be preferable when processing something twice is worse than missing it—for example, avoiding a duplicate payment. In practice, applications often use at-least-once delivery together with idempotent processing instead of relying on a perfect exactly-once guarantee.
The payment example helped. If a duplicate charge is worse than a missed transaction, then intentionally allowing a message to be dropped is the guarantee you actually want. Idempotent processing also seems more realistic than trusting exactly-once delivery.
That makes sense—I was reading “can provide” as the default behavior rather than as a list of configurable delivery modes. If the guarantee depends on the setup, then several options can be correct.