Yes, you can have exactly-once delivery
Claims that “exactly-once delivery” in distributed systems is impossible are challenged here by arguing that, with retries plus deduplication, higher layers can effectively see each message only once. Commenters push back that this conflates “delivery” (what happens on an unreliable channel) with “processing” (application behavior) and that formal impossibility results still apply unless you assume perfectly reliable components or bounded time/memory. The exchange highlights how much hinges on definitions, and why practitioners stress idempotent application logic even when middleware advertises “exactly-once” semantics.
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.