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

Message is a discrete communication unit emitted by a source and received by one or many consumers; in monolithic services it can be delivered via I/O, inter‑process communication, or method calls, while distributed systems rely on network protocols like UDP or TCP.

Unreliable communication channels make building large‑scale distributed systems complex.

Network Requests

In distributed systems the network is an unreliable channel; each request can end in success, failure, or timeout. A request’s result is only known after the response is received, and network conditions can cause loss or delay, contradicting the myth of a stable, trustworthy network.

Success and Failure

Even though the network is unstable, most of the time a request yields a deterministic result—either success or failure—allowing the caller to handle it similarly to local IPC calls.

Timeout

When a request times out, the caller may never receive a response, making it impossible to know whether the remote side processed the message; retries are required, but they introduce challenges for non‑idempotent operations, as repeated executions can cause side effects such as double transfers.

Message Delivery Semantics

Three common delivery guarantees exist:

At‑Most‑Once : The sender transmits the message once and does not retry, e.g., UDP.

At‑Least‑Once : The sender retries on timeout until a response is received, guaranteeing delivery but possibly causing duplicates.

Exactly‑Once : Theoretically impossible; systems achieve it by deduplication and idempotent processing on the consumer side.

Delivery Order

Network instability can reorder messages. To achieve ordered processing, consumers often use either sequence numbers (similar to TCP SEQ) or a state‑machine approach that defines allowed state transitions and ignores out‑of‑order or stale messages.

Sequence Numbers

Each message carries a monotonically increasing sequence number; consumers can block or discard messages based on gaps or expiration, ensuring ordered handling.

State Machine

Resources have defined states (e.g., pending → active → completed). Messages act as state‑transition events; once a resource reaches a final state, further messages are ignored, preventing inconsistencies even when delivery order is scrambled.

Protocols

Message queues implement these semantics. Common protocols include:

AMQP

Advanced Message Queuing Protocol defines queues, routing, durability, and security. Implementations such as RabbitMQ provide at‑most‑once and at‑least‑once guarantees and require idempotent handling for the latter.

MQTT

Built on TCP/IP, MQTT supports three QoS levels—at‑most‑once, at‑least‑once, and exactly‑once—by handling retries and deduplication at the protocol layer, making it suitable for constrained devices and unreliable networks.

Summary

Ensuring message delivery in distributed systems is complex because network communication is uncertain; developers must handle retries, timeouts, idempotency, and state management. Exactly‑once delivery cannot be guaranteed—messages will either be lost or duplicated, and systems must mitigate these outcomes.

Reference

Akka Message Delivery - At‑Most‑Once, At‑Least‑Once, and Exactly‑Once (Part 1, 2, 3)

Exactly‑once Support in Apache Kafka

Message Delivery Reliability (Akka Docs)

How Alibaba RocketMQ solves ordering and duplication

Message Queue Design Essentials (Meituan)

RabbitMQ vs Kafka – Message Delivery Semantics and Guarantees

You Cannot Have Exactly‑Once Delivery

Source: https://draveness.me/message-delivery