Why Exactly-Once Delivery Is Impossible: Understanding Message Delivery Semantics

Network Requests

In distributed systems a message is a discrete communication unit sent from a source to one or many receivers. In monolithic services messages travel via I/O, inter‑process communication, or method calls, while in distributed systems they travel over the network using protocols such as UDP or TCP.

The network is the most uncontrollable part of a computer system; requests may never reach the target service due to packet loss, node failures, or other issues, which is why the belief that "the network is stable and trustworthy" is a common misconception in distributed architecture.

Unreliable communication channels are a major reason why building large‑scale distributed systems is complex.

Network Request Outcomes

Each network request can end in one of three states: success, failure, or timeout. A successful response means the request was processed and a definitive answer was returned. Failures occur when the request reaches the target but cannot be processed correctly. Timeouts happen when the request never receives a response, often due to packet loss or node errors.

Timeout Handling

When a request times out, the caller cannot know whether the target received the request or not. Therefore, callers must set an appropriate timeout value and, if the deadline passes, treat the request as failed and possibly retry. Retries can cause duplicate processing, especially for non‑idempotent operations.

Message Delivery Semantics

To reason about reliability, we classify delivery semantics into three categories:

At‑Most‑Once

The sender transmits the message once and never retries, regardless of whether the receiver acknowledges it. UDP provides this guarantee, but messages may be lost.

At‑Least‑Once

The sender retries on timeout until a response is received, ensuring the message is eventually delivered, but duplicates may occur.

Exactly‑Once

True exactly‑once delivery is impossible at the protocol level; implementations achieve it by combining at‑least‑once delivery with deduplication mechanisms such as unique keys or idempotent processing.

Deduplication typically uses a key generated by the producer; the consumer checks this key to discard duplicates. Idempotent operations or replay‑safe designs are also essential.

Delivery Order

Network instability can cause messages to arrive out of order. Two common techniques to handle ordering are sequence numbers and state machines.

Sequence Number

Each message carries a monotonically increasing sequence number, similar to TCP’s SEQ field. Consumers can reorder or discard out‑of‑order messages based on these numbers.

SEQ

State Machine

Resources transition through predefined states (e.g., pending → active → completed). By enforcing state transitions, consumers can ignore messages that would move a resource to an invalid state, effectively handling out‑of‑order deliveries.

Messaging Protocols

Message queues implement the above semantics. Two widely used protocols are:

AMQP

Advanced Message Queuing Protocol defines queues, routing, reliability, and security. Implementations such as RabbitMQ support at‑most‑once and at‑least‑once semantics; exactly‑once requires idempotent handling.

MQTT

Built on TCP/IP, MQTT is designed for low‑power or unreliable networks. It offers three Quality‑of‑Service levels that map directly to at‑most‑once, at‑least‑once, and exactly‑once delivery.

Summary

Ensuring message delivery in distributed systems is inherently difficult because network communication is unreliable. Developers must handle retries, timeouts, idempotency, and ordering. While true exactly‑once delivery cannot be guaranteed, combining at‑least‑once delivery with deduplication or idempotent processing provides practical reliability.

References

Akka Message Delivery – At‑Most‑Once, At‑Least‑Once, Exactly‑Once

Exactly‑once Support in Apache Kafka

Message Delivery Reliability (Akka Docs)

RabbitMQ vs Kafka – Delivery Semantics

You Cannot Have Exactly‑Once Delivery