At-Most-Once vs. At-Least-Once Delivery

Every message queue eventually reaches the same architectural decision: what should happen if processing a message fails?

It sounds like a simple question, but the answer influences almost every part of a queue system. Reliability, performance, storage requirements, retry logic, and even application design are all affected by the delivery guarantee a queue provides.

While building QueueForge, this has been one of the topics we've spent considerable time evaluating. There isn't a universally correct answer because every workload has different requirements.

Why Delivery Guarantees Exist

Distributed systems fail. Workers crash, servers restart, network connections time out, and acknowledgements occasionally never reach the queue.

Without clearly defined delivery guarantees, it's impossible to know how a queue should behave when these situations occur.

Should the message be discarded? Should it be retried? Should another worker receive it? Those decisions define the delivery semantics of the queue.

At-Most-Once Delivery

At-Most-Once delivery prioritizes simplicity and throughput.

As soon as a worker receives a message, the queue considers its job complete. The message is removed immediately and won't be delivered again.

If the worker crashes halfway through processing, the message is lost permanently.

While that sounds undesirable, there are many workloads where this trade-off is perfectly acceptable.

Consider a system collecting anonymous analytics events. Losing one page view out of several million is unlikely to affect overall statistics, while processing duplicate events may produce misleading results.

Since no acknowledgement tracking or retry mechanism is required, At-Most-Once delivery generally provides lower latency and higher throughput.

At-Least-Once Delivery

At-Least-Once delivery focuses on reliability instead.

Rather than removing a message immediately, the queue keeps it until the worker explicitly confirms successful processing.

If that confirmation never arrives, whether because of a crash, timeout, or network interruption, the queue assumes processing failed and delivers the message again.

This dramatically reduces the risk of silently losing messages, making it the preferred choice for many production workloads.

Why Duplicate Messages Happen

One of the biggest misconceptions about At-Least-Once delivery is that duplicate messages indicate something has gone wrong.

In reality, duplicates are often the expected outcome of a reliable system.

Imagine a worker processes a message successfully and immediately sends an acknowledgement back to the queue. If the network connection fails before the acknowledgement arrives, the queue has no reliable way of determining whether the message was actually processed.

From the worker's perspective, everything completed successfully. From the queue's perspective, the acknowledgement never arrived.

In that situation, retrying the message is usually the safest decision. Processing a message twice is often preferable to losing it entirely.

Idempotency Becomes Important

Because duplicate deliveries are possible, applications consuming messages should ideally be idempotent.

An idempotent operation produces the same result regardless of how many times it is executed.

For example, updating an order status to Completed is typically idempotent. Charging a customer's credit card usually is not.

Common approaches include unique message identifiers, idempotency keys, deduplication tables, or database constraints.

Which One Is Better?

Neither.

The right choice depends entirely on the problem you're solving.

If maximum throughput is more important than perfect reliability, At-Most-Once delivery may be the right fit.

If losing a message is unacceptable, At-Least-Once delivery is generally the better choice, provided your application can safely handle duplicate processing.

What About QueueForge?

While designing QueueForge, we quickly realized there isn't a single delivery guarantee that works best for every application.

Some workloads prioritize maximum throughput and can tolerate occasional message loss. Others require reliable processing and are willing to handle duplicate deliveries in return.

Rather than forcing users to choose one model, QueueForge is being designed to support both At-Most-Once and At-Least-Once delivery. The delivery guarantee can be selected when creating a queue, allowing each workload to use the model that best matches its requirements.

This flexibility lets developers optimize individual queues instead of making a platform-wide compromise. An analytics queue, for example, might use At-Most-Once delivery, while an order processing queue on the same QueueForge instance can use At-Least-Once delivery.

We believe message queues should adapt to an application's requirements. Not the other way around.

As QueueForge continues to evolve, we'll continue sharing the architectural decisions behind the platform and why we made them.

If you'd like to follow our development journey and receive future engineering articles, consider subscribing to our newsletter.

See you next time,
The QueueForge Team