Up to here, almost every rule of the Kladde lived in exactly one aggregate: a quote, an appointment, a deal, each in its grain, each with its own transaction. As soon as two parts talk to each other, through a message, a mail or a foreign interface, that one transaction is gone. This module shows how a system stays consistent anyway. This first lesson lays the ground: what a delivery can promise, what it cannot, and why a timeout is the most dangerous answer of all.
Three promises
Whoever sends a message can choose between two errors, but cannot rule out both at once:
| Promise | How the sender works | What can go wrong |
|---|---|---|
| at most once | It sends once and never retries. | The message gets lost. |
| at least once | It retries until an acknowledgment comes. | The message arrives twice. |
| exactly once | Doesn't exist as a delivery. | – |
“Exactly once” exists only as an effect, not as a delivery: The sender delivers at least once, and the receiver recognizes repeats and applies each message only once. Microsoft's documentation calls this effectively once. Service Bus does it the same way: With peek-lock, the default, it delivers at least once; with “Receive and Delete” at most once.
Which promise fits depends on the message. A “currently online” indicator may get lost; the next one comes anyway. A booking confirmation may neither get lost nor arrive twice. It needs both: retrying and recognizing.