At-most-once, at-least-once, exactly-once: the three delivery contracts

A payment worker processes a “charge $50” message and crashes before telling the queue it is done. The queue redelivers. The customer is charged twice. This is not a bug in your code — it is the default behaviour of every production queue in the world.

The three contracts

Every message queue offers a delivery contract — a guarantee about how many times a message reaches a consumer when failures happen.

At-most-once. The broker sends the message once and never retries. If the network drops the message, it is gone. No duplicates, but possible loss. Use case: debug logs, non-critical telemetry. Never use for money, orders, or any event where loss has business consequences.

At-least-once. The broker retries until the consumer sends an explicit acknowledgement (ack). If the ack is lost, the broker redelivers. The message arrives at least one time, but possibly more. At-least-once is the default in SQS, RabbitMQ (with ack), and Kafka with default settings.

Exactly-once. Every message is processed exactly one time regardless of retries. This is what you want. The problem: pure exactly-once delivery over an unreliable network is mathematically impossible — the Two Generals’ Problem proves that two parties over an unreliable channel can never be certain they both agree on the same fact. You cannot guarantee both sides know a message was delivered exactly once.

What you can achieve is exactly-once processing — the consumer’s side effect (charge a card, send an email, update a row) happens exactly once, even if the broker delivers the message more than once. The trick is an idempotent consumer.

Why at-least-once is the safe default

At-most-once accepts loss. For a payment system, a lost “charge customer” message means a missed transaction — unacceptable. At-least-once accepts duplicates. A duplicate “charge customer” message means charging twice — also bad, but fixable on the consumer side. Exactly-once delivery is not achievable without adding expensive coordination.

The industry convergence: use at-least-once delivery + make the consumer idempotent. The consumer checks “have I already processed this message ID?” before acting. Duplicates are ignored. The queue can retry freely without causing harm.