At-Least-Once Delivery
At-least-once delivery tries to keep a message from being lost, but the same message may arrive more than once. The consumer must handle repeats safely.
deliver -> process -> acknowledge/delete; missing acknowledgement -> redeliver; event ID -> dedupeevt_784deliver -> process -> acknowledge/delete; missing acknowledgement -> redeliver; event ID -> dedupeJOBAnother example
A worker saves receipt `evt-42` but stops before deleting the Amazon SQS message. SQS later delivers the same message again. The next worker sees the saved event ID and returns the existing receipt instead of making a second one.
Main parts
- 01Stable message ID
- 02Delivery attempt
- 03Result made by the worker
- 04Acknowledgement or delete
- 05Redelivery path
- 06Duplicate record
Use it when
Use this rule when losing one job is worse than handling it twice. Give every message a stable ID. A repeated message must not charge, email, or save twice.
Do not use it when
Delivery does not mean the work succeeded. Do not promise exactly one result. Charges or outside actions need their own duplicate guard.
Name used in code
deliver -> process -> acknowledge/delete; missing acknowledgement -> redeliver; event ID -> dedupe Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review At-Least-Once Delivery for this system while keeping data correct, secure, and easy to operate. User context: A worker saves receipt `evt-42` but stops before deleting the Amazon SQS message. SQS later delivers the same message again. The next worker sees the saved event ID and returns the existing receipt instead of making a second one. Technical concept or control: At-Least-Once Delivery. Why it fits: Use this rule when losing one job is worse than handling it twice. Give every message a stable ID. A repeated message must not charge, email, or save twice. Do not use it when: Delivery does not mean the work succeeded. Do not promise exactly one result. Charges or outside actions need their own duplicate guard. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of At-Least-Once Delivery. Definition: At-least-once delivery tries to keep a message from being lost, but the same message may arrive more than once. The consumer must handle repeats safely. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.