At-Least-Once Delivery

At-least-once delivery means a message is delivered one or more times, with redelivery possible when processing or acknowledgment is uncertain. Consumers therefore need to tolerate duplicates, commonly through idempotent processing or deduplication.

A producer sends a message to a broker, and the broker retains it until it considers delivery or acknowledgment successful. If the consumer processes the message but the acknowledgment is lost, delayed, or the consumer crashes before acknowledging, the broker may deliver the same message again.

This provides stronger delivery durability than at-most-once delivery because a transient failure can trigger another delivery attempt. The trade-off is that the consumer cannot generally assume each message is observed exactly once.

A common consumer strategy is idempotency: processing the same logical message multiple times produces the same final business state. For example, a payment operation can use a unique transaction ID and reject or ignore subsequent attempts for that ID.

Deduplication can also be implemented by recording processed message IDs in durable storage. In Java services, this often means combining a broker acknowledgment mechanism with a database transaction, unique constraint, or idempotency table. The exact guarantees depend on the broker, acknowledgment protocol, storage system, and failure boundaries.

At-least-once delivery does not mean that duplicates are guaranteed to occur, nor does it mean messages can never be lost under every failure scenario. It describes the delivery semantics under the system's stated durability and retry assumptions.

Key points

• Messages may be delivered more than once.
• Redelivery can happen when acknowledgment is lost or processing outcome is uncertain.
• Consumers should make processing idempotent or explicitly deduplicate messages.
• Durable deduplication state can use message IDs, unique constraints, or idempotency records.
• At-least-once semantics trade duplicate processing risk for stronger delivery than at-most-once semantics.

Interview questions

What does at-least-once delivery mean?

It means the messaging system attempts to make a message available to the consumer at least once under its delivery guarantees. A message can be delivered multiple times because a retry may occur after an uncertain processing outcome. Therefore, consumers must tolerate duplicates. A common solution is idempotent processing or deduplication.

Why can a consumer receive a duplicate after successfully processing a message?

Processing and acknowledgment are often separate operations. The consumer may complete the business operation and then fail before the broker receives the acknowledgment, or the acknowledgment itself may be lost. The broker cannot safely distinguish that situation from a consumer that never processed the message. It therefore retries the message, producing a duplicate.

How would you design an idempotent Java consumer?

I would assign each logical message a stable unique identifier and persist the processing decision in durable storage. The business update and the insertion of that identifier should be coordinated so that a retry cannot apply the business effect twice. A database unique constraint is useful for enforcing this invariant under concurrent consumers. After successful processing, the consumer can acknowledge the message.

Can at-least-once delivery provide exactly-once business effects?

It can be used as a foundation for exactly-once effects within a carefully defined transactional boundary, but the delivery guarantee itself does not provide that property. The consumer can use idempotency keys, durable deduplication, transactional updates, or transactional messaging patterns to make retries safe. The scope matters because coordinating a broker with an unrelated external system can introduce another failure boundary. Therefore, I would state exactly which operations the guarantee covers rather than claiming universal exactly-once behavior.

What are the main trade-offs between at-most-once, at-least-once, and exactly-once processing?

At-most-once favors avoiding duplicates but can lose messages when failures occur. At-least-once favors retrying delivery but requires duplicate-safe consumers. Exactly-once aims to constrain duplicates within a specified system boundary, but it usually requires stronger coordination or transactional mechanisms and does not automatically make arbitrary external side effects exactly once. The appropriate choice depends on the business consequence of loss versus duplication and the guarantees provided by the infrastructure.