Delivery Guarantees

Messages travel over a network, and networks are not perfect. Sometimes a message gets lost. Sometimes a worker crashes right after doing the job but before saying “done”, so the system isn’t sure if it finished. That raises a scary question for anything that matters, like a payment:

• If we’re not sure a message was handled, should we send it again and risk doing the job twice? Or skip it and risk never doing it at all?

This is what delivery guarantees are about. There are three levels, and each one is a different answer to that question. Let’s go through all three, because picking the wrong one can charge a customer twice or lose their order.

🎯 The Three Guarantees

Here’s the whole map in one line each, then we’ll dig in:

• At-most-once: the message is delivered zero or one time. It might get lost, but it’s never repeated.
• At-least-once: the message is delivered one or more times. It’s never lost, but it might repeat.
• Exactly-once: the message is delivered one time, no more, no less. The ideal, but the hardest to build.

Notice the tension. The easy options either risk losing a message or risk repeating it. Getting truly exactly-once is expensive. Let’s see why.

1️⃣ At-Most-Once

At-most-once means the sender fires the message and doesn’t worry about it. No checking, no retrying. If it arrives, great. If it’s lost, oh well.

• It’s the simplest and fastest, since there’s no extra checking.
• But messages can quietly disappear, and you’d never know.

So you’d only use this when losing a message now and then is totally fine. Like a stream of “current temperature” readings, where missing one doesn’t matter because another comes right behind it.

2️⃣ At-Least-Once

At-least-once means the sender keeps trying until it gets a confirmation that the message was handled. If it doesn’t hear back, it sends again.

• This guarantees the message is never lost. Good.
• But it can cause duplicates. If a worker did the job but crashed before confirming, the sender re-sends, and the job runs twice.

This is the most common choice in real systems, because losing data is usually worse than handling something twice. But you have to deal with those possible duplicates, which leads to the next idea.

🛡️ Making At-Least-Once Safe With Idempotency

Here’s the trick that makes at-least-once work in practice: idempotency. An idempotent action gives the same result no matter how many times you do it.

So even if a message arrives twice, an idempotent handler makes the duplicate harmless. An example:

# Not idempotent — runs twice, charges twice
balance = balance - 100

# Idempotent — uses a unique payment id
if payment "PAY-123" not already processed:
    charge the card
    mark "PAY-123" as processed
# A second copy of PAY-123 sees it's done, and skips

Reading that: the first version blindly subtracts money every time, so a duplicate double-charges. The second version checks a unique ID first, so a duplicate is ignored. That’s how you safely use at-least-once: make the work idempotent.

3️⃣ Exactly-Once

Exactly-once means the message is handled one time, period. No loss, no duplicates. This sounds perfect, and it’s what everyone wants.

The catch: true exactly-once is very hard and costly. The system has to carefully track every message and coordinate so that retries never cause a second effect. That coordination:

• Slows things down, because of all the extra tracking and checking.
• Adds complexity, which means more things that can break.

Some modern tools (like Kafka in certain setups) offer exactly-once for specific cases. But often the smarter move is at-least-once plus idempotency, which gets you the same end result more cheaply.

📊 The Three Compared

Here they are side by side.

⚠️ Common Mistakes and Misconceptions

A few things to keep straight:

• “Just use exactly-once everywhere, it’s the best.” It’s the most expensive and complex. Most systems get the same safety with at-least-once plus idempotent handlers.
• “At-least-once means I don’t need to handle duplicates.” Wrong, and this causes real bugs. At-least-once can repeat messages, so your handler must be idempotent.
• “At-most-once is fine, networks rarely fail.” They fail often enough to matter. For anything important, the risk of silently losing a message is too high.

🧩 What You’ve Learned

Nice work. Here’s the recap:

• ✅ At-most-once may lose messages but never repeats them; use it only for data you can afford to lose.
• ✅ At-least-once never loses messages but may repeat them; it’s the most common choice.
• ✅ Idempotency makes duplicate messages harmless, which is what makes at-least-once safe.
• ✅ Exactly-once is the ideal but is costly and complex, so at-least-once plus idempotency is often used instead.

🚀 What’s Next?

You know how to trust that messages arrive. Now let’s talk about their order.

• Message Ordering covers whether messages arrive in the order they were sent.
• Idempotency digs deeper into the trick that makes retries safe.

Get these down and you’ll be able to design messaging you can actually rely on.