Message delivery Guarantees

Introduction

Notifications are an integral part of modern systems—whether it’s an email alert, a push notification, or a message in a chat app. But ensuring that a notification reaches the user reliably isn’t as straightforward as it seems. Depending on the use case, different delivery guarantees come into play.

In this post, I will summarize the three key delivery models: At Most Once, At Least Once, and Exactly Once—what they mean, how they work, and when to use them. This should help you design a robust notification system that meets your business requirements. This is also extensible to other designs that have producer consumer systems.

1. At Most Once

“I’ll send it, but I won’t check if you got it.”

In this model, a message is delivered zero or one time—meaning there’s a chance the recipient may never receive it. Once sent, there’s no retry mechanism. If something fails (e.g., a network issue), the message is lost forever.

Use Cases

• Non-critical notifications like promotional emails or updates
• Telemetry data where occasional loss is acceptable
• Real-time stock price updates (where old data becomes irrelevant)

Implementation

• Messages are sent without acknowledgment (ACK) from the receiver.
• No retry logic or persistence.
• Low latency but unreliable.

2. At Least Once

“I’ll keep sending it until I’m sure you got it.”

Here, a message is delivered at least once, but it may arrive multiple times. The sender ensures delivery by retransmitting until it gets an acknowledgment (ACK) from the receiver. However, if the ACK gets lost in transit, the sender may resend the message even though the receiver already got it—resulting in duplicates. Depeding on the system, duplicates can be handled.

Use Cases

• Payment transactions notification to users (where it's better to notify user to do payment twice than miss a payment), Payment should be processed once though
• Order confirmations in e-commerce (as long as duplication is handled)
• Critical alerts (e.g., fraud detection notifications)
• Emails, SMS notifications (some providers retry if not acknowledged).

Implementation

• The sender retries until ACK is received.
• The receiver needs idempotency handling to avoid processing the same message multiple times.
• Reliable but may cause duplication.

3. Exactly Once

“I’ll make sure you get it exactly once, no more, no less.”

This is the most complex and expensive model, where each message is guaranteed to be delivered exactly once with no duplicates. It requires sophisticated mechanisms to track message status and prevent reprocessing. It guarantees no loss or duplication but comes with higher overhead.

Use Cases

• Banking transactions (a money transfer should happen only once)
• IoT applications (sensor data should not be duplicated)
• Event-driven systems (where duplicate processing can cause inconsistencies)

Implementation

• Deduplication mechanisms ensure the same message isn’t processed twice.
• Requires transactional message queues (like Kafka, RabbitMQ, or AWS SQS FIFO).
• Higher overhead but ensures correctness.

Choosing the Right Model: Trade-offs Matter

There’s no one-size-fits-all solution. Your choice depends on:

• Cost & Complexity – Exactly Once is costly; At Most Once is simple.
• Use Case Criticality – Can you tolerate occasional loss? If yes, go for At Most Once.
• Duplicate Handling – If your system can handle duplicates, At Least Once might be a good balance.

Final Thoughts

Understanding these delivery guarantees is crucial when designing a scalable and reliable notification system. Each model has its own trade-offs, and the right choice depends on your specific business needs.

Would love to hear your thoughts—what delivery guarantees have you implemented in your systems? 🚀