At-Least-Once Delivery

Overview

At-Least-Once Delivery is a message-delivery guarantee in which the system keeps retrying until delivery is acknowledged, so a message should arrive but may arrive more than once. Changes to At-Least-Once Delivery should be tested against normal, failed, delayed, duplicate, and recovery paths that apply to the operation.

The principal risks include duplicate payments or fulfillment, repeated notifications, retry storms, poison messages, unbounded storage growth, and acknowledgements occurring before durable processing. It prioritizes avoiding loss over avoiding duplicates and therefore requires consumers to make repeated processing safe.

A production implementation should use durable message storage, explicit acknowledgement, bounded retries, dead-letter handling, stable event identifiers, idempotent consumers, and observability for redelivery. Testing At-Least-Once Delivery should cover boundary values, dependency failure, restart recovery, and incompatible versions where they affect the workflow.

Useful measures include redelivery rate, acknowledgement latency, duplicate-detection rate, dead-letter volume, retry age, and unprocessed-message backlog. At-Least-Once Delivery is closely connected to Idempotent Consumer, Webhook Deduplication, and Automatic Retry. Operational metrics for At-Least-Once Delivery should use stable denominators and separate technical activity from successful business completion.

The production boundary for At-Least-Once Delivery should identify the authoritative system, responsible owner, accepted states, and recovery path. For At-Least-Once Delivery, identifiers and timestamps should remain stable enough to trace the technical action to its final business outcome.

Monitoring for At-Least-Once Delivery should distinguish transport success, processing success, and the final external or financial result. Evidence for At-Least-Once Delivery should preserve the input, configuration version, actor or service, decision, downstream reference, and final outcome. The At-Least-Once Delivery runbook should define who can retry, cancel, replay, reconcile, communicate, and approve an exception.