Delivery Semantics
Practice this topic in a realistic system design interview
Over an unreliable network, a sender cannot always know whether a message was processed. So every messaging system has to choose how it behaves when that uncertainty appears.
In this chapter, we'll look at what at-most-once, at-least-once, and exactly-once really mean, and how real systems avoid losing or duplicating messages.
Suppose an order service sends a message to a payment service saying, "charge this customer $50." The order service waits for a response, but nothing comes back.
What happened? There are three possibilities:
- The message was lost before it reached the payment service.
- The payment service received it, charged the customer, and then the response was lost on the way back.
- The payment service is simply slow, and the response is still on its way.
From the sender's side, these three cases look identical. All it sees is silence.
Now the sender has to make a decision. If it does not retry, the payment may never happen. If it does retry, the customer may be charged twice.
This is the core problem behind delivery semantics.
1. The Three Guarantees
There are three common delivery guarantees:
- At-most-once: A message is delivered once or not at all. It may be lost, but it is never duplicated.
- At-least-once: A message is never lost, but it may be delivered more than once.
- Exactly-once: Every message affects the system one time, with no loss and no duplicates.
| Guarantee | Retry? | When the consumer acknowledges | Main Risk |
|---|---|---|---|
| At-most-once | No | Before processing | Message loss |
| At-least-once | Yes, until acknowledged | After processing | Duplicates |
| Exactly-once | Yes | After processing, plus deduplication | More complexity |
Each guarantee comes from a specific choice about when to retry and when to acknowledge. Let's look at each one in detail.