Guaranteed Delivery

Guaranteed Delivery ensures that once a message is accepted by the messaging system, it will eventually be delivered to the receiver even if the sender, broker, or receiver crashes in between. It trades performance for reliability by persisting messages to durable storage so they survive failures.

The problem it solves is message loss. In-memory messaging is fast but volatile: a broker restart or crash loses everything queued. For workflows where losing a message means a lost order, payment, or instruction, this is unacceptable. Guaranteed delivery makes durability a property of the channel.

How It Works

The broker writes each message to persistent storage (disk, replicated log, or database) before acknowledging the producer. The producer's send completes only once the message is safely stored, so the producer knows it will not be lost. On the consumer side, the broker keeps the message until the consumer acknowledges successful processing; an unacknowledged message is redelivered after failure. Replication across nodes protects against the loss of any single broker.

This end-to-end chain — durable on receipt, retained until acknowledged, replicated for fault tolerance — is what guarantees delivery. The cost is the latency and throughput overhead of persistence and replication.

producer --persist+ack--> [ durable broker (replicated) ] --retain until ack--> consumer

When to Use It

Use it whenever message loss is unacceptable: financial transactions, order processing, event sourcing, and audit trails. It underpins reliable asynchronous workflows and is the default expectation for business-critical messaging.

Avoid it for high-volume, low-value telemetry where speed matters more than the occasional lost message; non-persistent channels are far faster there.

Trade-offs

Guaranteed delivery costs throughput and latency because every message hits durable, often replicated storage before acknowledgment. It also typically provides at-least-once rather than exactly-once semantics, so consumers must be idempotent to handle redelivery. Storage capacity and retention must be managed. The benefit is that no accepted message is ever silently lost.

Related Patterns

It pairs with the Idempotent Receiver to handle the duplicates that reliable redelivery causes, and with the Dead Letter Channel for messages that fail repeatedly. A Message Store can retain copies for audit. It is a quality applied to a Message Channel.

Example

Apache Kafka writes messages to a replicated, on-disk log with a configurable replication factor and acks=all, so a producer's send is acknowledged only after the message is persisted on multiple brokers. Even if a broker fails, consumers can still read every committed message from a replica.