Reliable delivery can include duplicates
A messaging system retrying without a reliable acknowledgment can deliver a message again. At-least-once semantics admit such duplicates, so a prior receipt does not establish that no future delivery will occur.
Amazon SQS standard queues retain copies on multiple servers. An unavailable copy during receipt or deletion can later reappear. AWS consequently calls for applications that tolerate repeated processing rather than assuming every copy can never return.
References: [1]
Acknowledgments cover defined interaction boundaries
A broker confirming publication differs from a consumer acknowledging processing. RabbitMQ explicitly separates these mechanisms: publisher confirms do not know consumer state, and consumer acknowledgments are not business replies to the original publisher.
With manual acknowledgments, RabbitMQ requeues unacknowledged deliveries when their channel or connection closes. This supports recovery but can deliver to one consumer a message previously given to another. Responsibility is not determined solely by a connection remaining open.
References: [2]
Delivery count and business effects are separate
If a business update finishes but its acknowledgment is lost, redelivery should not blindly repeat a charge or append. Idempotent operations, stable request identity, and consistently retained outcomes can constrain repeated delivery to the intended effect.
At-least-once is not an unconditional promise covering every failure or unlimited downtime. It must be interpreted through the service’s storage, acknowledgment, and recovery contract. Reliability requires examining publication, broker custody, processing, and final effects separately.