Yes, you can have exactly-once delivery
Scope of “exactly-once”
- Core disagreement is over what “delivery” means.
- One camp: “delivery” is about messages crossing an unreliable channel (e.g., network), regardless of what the receiver does afterward. Under that definition, exactly-once delivery is impossible in general.
- Other camp: you can define the “receiver” to be downstream of a deduplication layer on a reliable substrate, and then that receiver does see each logical message exactly once.
Delivery vs. processing
- Many argue the standard and useful distinction is:
- Delivery: a message arrives at the system endpoint, possibly multiple times.
- Processing: the system updates durable state in response.
- Exactly-once processing is achievable atop at-least-once delivery plus idempotency/dedup; exactly-once delivery (at the unreliable-channel boundary) is not.
- Critics say blurring this distinction misleads developers and has caused real bugs (e.g., in messaging/streaming systems advertised with “exactly-once semantics”).
Memory, time, and impossibility arguments
- Objection: any generic dedup requires tracking seen messages; without bounds on time, rate, or size, this needs unbounded memory.
- If you prune dedup state or give up after N retries, you lose strict at-least-once or exactly-once guarantees.
- Some point out that, by the same reasoning, even “at-least-once delivery” is idealized, since retries are also bounded in practice.
Practical engineering vs. theory
- Several comments stress that in real systems, “good enough” (extremely high probability) is fine, analogous to CAP or compression discussions.
- Idempotent handlers, message IDs, expirations, and transactional patterns are common tools.
- Some messaging products and XA/JMS stacks market “exactly-once delivery,” which others denounce as at-least-once + transactions/idempotency rebranded.
Semantics, pedagogy, and human communication
- A significant subthread argues this is largely a semantic dispute that obscures the real lesson: applications must handle retries and duplicates.
- Others say precise, conventional terminology is crucial to avoid confusion, especially for less-experienced engineers.
- The article’s stated intent—to comment on human communication via this debate—was noted, but many participants focused almost entirely on the technical semantics.