At-most-once delivery

What is at-most-once delivery?

At-most-once delivery means a message is delivered zero or one time. It may be lost, but it should not arrive twice. The sender does not keep retrying until it gets proof of success.

This is sometimes called fire and forget. The sender sends the message and moves on. If the network drops it, the broker fails, or the receiver crashes before processing it, there is no automatic second attempt.

At-most-once is the opposite trade-off from at-least-once delivery. At-least-once accepts duplicates to avoid loss. At-most-once accepts loss to avoid duplicates and reduce overhead.

How at-most-once works

The mechanics are intentionally simple. The sender does not wait for an acknowledgement before considering the message done, or the consumer commits its position before processing the message. Either way, a failure after that point means the system moves on.

In Kafka-like systems, a consumer can create at-most-once behaviour by committing its offset before processing the event. If it crashes after the commit but before the work finishes, it restarts from the next offset. The skipped event is gone from that consumer's point of view.

In MQTT, QoS 0 is the classic at-most-once mode. The message is sent without a delivery handshake. That keeps the protocol light and fast, which is useful for small devices and high-volume telemetry.

The three delivery guarantees

• At-most-once: zero or one delivery. Fast and simple, but loss is possible.

• At-least-once: one or more deliveries. Loss is avoided, but duplicates are possible.

• Exactly-once: one effective result. Stronger, but it requires coordination and has stricter boundaries.

The right choice depends on what hurts more: a missing message or a duplicate message.

When at-most-once is a good fit

At-most-once fits data where individual messages are useful but not precious.

• Sensor readings. If a device sends temperature every second, missing one reading is often harmless because the next reading arrives immediately.

• High-volume telemetry. App events, infrastructure metrics, and clickstream samples may be analysed in aggregate. One missing event out of millions does not change the decision.

• Sampling. If the dataset is intentionally incomplete, at-most-once may be enough.

• Best-effort notifications. Some low-value signals are useful when present but not worth retry infrastructure.

At-most-once is a bad fit when each event changes money, stock, access rights, legal status, or customer state. Payments, orders, invoices, inventory movements, and account changes need a stronger guarantee.

Why teams still choose it

At-most-once removes work. There are fewer acknowledgements, fewer retries, fewer duplicate checks, and less state to store. That can reduce latency and cost in systems that process enormous volumes of low-value events.

It also keeps producers and consumers simpler. A small device on an unreliable network may not have the memory, battery budget, or protocol complexity for reliable delivery. A monitoring system may prefer a slightly incomplete graph over a backlog that overwhelms the service.

The danger is choosing at-most-once because it is easy, not because loss is acceptable. The test is blunt: if this one message disappears, will a customer, accountant, auditor, or operations team care? If yes, do not use at-most-once.

What to watch out for with at-most-once delivery

Loss can be silent
A missing event often creates no error. If loss matters even occasionally, add counters, sampling checks, or reconciliation against a source of truth.

Aggregates hide the pain
A dashboard may look stable while a small segment loses too many events. Watch loss by source, region, device type, customer group, and total volume.

It is not a queue default for business workflows
Most business queues lean toward at-least-once because missing work is worse than doing a dedup check.

Do not mix semantics casually
If one stage is at-most-once, a later at-least-once stage cannot bring lost messages back. The weakest delivery point sets the ceiling for the whole path.