Distributed Systems

At-Least-Once Delivery

Also known as: at least once, delivery guarantee

Definition

At-least-once delivery guarantees a message reaches its consumer one or more times, never zero. The broker redelivers until it receives an acknowledgement, so a consumer that crashes after processing but before acking will see the message again. Duplicates are the price of never losing a message.

Last reviewed · Part of the Architecture Glossary

In practice

Kafka, SQS, RabbitMQ and every other production broker default to at-least-once because the alternative — acking before processing — silently drops messages when a consumer dies mid-work. The ordering that creates duplicates is unavoidable:

  1. Broker delivers message M.
  2. Consumer processes M — the side effect has happened.
  3. Consumer crashes before the ack reaches the broker.
  4. Broker's visibility timeout expires; it redelivers M.

Nothing in that sequence is a bug. The design response is not to eliminate step 4 but to make step 2 idempotent, typically with a processed_messages table keyed by message ID and written in the same transaction as the business effect.

When it matters

Whenever a side effect leaves your process: sending email, charging a card, calling a partner API, incrementing a counter. Pure reads and last-write-wins updates tolerate duplicates for free; anything additive does not.

Common mistake

Sizing the visibility timeout from the average processing time. A p99 job that takes 40 seconds against a 30-second timeout gets redelivered while the first attempt is still running — so now two workers process the same message concurrently, and your duplicate-suppression table needs to handle a race, not just a repeat.

See also

Go deeper