At-Least-Once Delivery
A delivery promise that keeps retrying so a message arrives, with the tradeoff that the same message can arrive more than once.
See it
What it is
At-least-once delivery means the sender or broker keeps trying until it gets an acknowledgement, so a message should arrive one or more times. The price of not quietly dropping work is duplication. Amazon SQS standard queues make this tradeoff explicitly, and webhook systems usually behave the same way.
Reach for it when losing a payment event, order, or background job is worse than processing a repeat. Make the consumer idempotent: attach a stable event ID, record which IDs succeeded, and make a second delivery produce no extra side effect.
The classic duplicate happens when processing succeeds but the acknowledgement is lost. The broker cannot tell success from silence, so it delivers again. Acknowledging before durable work creates the opposite bug, where a crash loses the message. Acknowledge only after the result is committed, and size the visibility timeout so normal processing can finish.
Ask AI for it
Build an at-least-once Amazon SQS consumer. Read MessageId and ReceiptHandle, extend the visibility timeout for long jobs, commit the business change and a processed-message record in one database transaction, then call DeleteMessage only after commit. Make duplicate MessageId values no-ops, retry transient failures with exponential backoff plus jitter, and test the case where the commit succeeds but DeleteMessage never reaches SQS.