At-Least-Once Delivery

Overview

Understand the idea

At-least-once delivery is a messaging guarantee that a successfully queued event will be delivered one or more times under the system's documented reliability assumptions. It trades possible duplicates for reducing event loss. Many webhook systems and job queues work this way because a sender cannot know whether an endpoint completed processing if the network response disappears.

What actually happens

The sender transmits an event and expects acknowledgment. If it times out or receives a retryable error, it may transmit the event again. That means the receiver must perform business operations idempotently and store a durable record of processed event IDs. Processing and acknowledgment ordering also matter: acknowledging before any durable work can lose an event after a crash, while executing an irreversible side effect before recording progress can produce duplicates after restart. Reliable workflows use transactional state, outbox/inbox patterns or equivalent safeguards.

Designers sometimes assume exactly-once execution because a queue advertises exactly-once producer semantics, but a downstream database write and wallet payout remain separate systems. A receiver should atomically mark work as accepted alongside the business-state change where feasible, or use an outbox so side effects can be retried safely. Define what acknowledgment means: accepted for processing, durably stored, or finished. That distinction determines when a sender should retry and what happens during a power failure between processing stages.

Decisions and failure cases

At-least-once is not exactly-once business execution. Provider-specific retention and retry rules can still lead to gaps, so periodic reconciliation remains necessary. Do not delete a valid duplicate blindly before checking whether the associated action completed after a partial failure.

Related concepts

Reconciliation Break, API Key Rotation, Address Poisoning.

Further reading

Stripe webhook processing.