# Exactly-Once Delivery May Not Be What You Want

DevFeed: [Exactly-Once Delivery May Not Be What You Want](<https://devfeed.tech/articles/exactly-once-delivery-may-not-be-what-you-want-12466.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2014/11/15/exactly-once.html>)

Author: Marc Brooker

Published: 2014-11-15T00:00:00Z

Content type: opinion

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Messaging](<https://devfeed.tech/topics/messaging.md>), [Resilience](<https://devfeed.tech/topics/resilience.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [databases](<https://devfeed.tech/tags/databases.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [messaging](<https://devfeed.tech/tags/messaging.md>), [resilience](<https://devfeed.tech/tags/resilience.md>)

## AI overview

The article argues that exactly-once message delivery is different from the exactly-once processing that most systems builders actually need. It explains how distributed systems use redundancy in space to tolerate node failures and redundancy in time to tolerate message loss, while noting that no general solution may exist for ensuring every side effect occurs exactly once.

## Source excerpt

Exactly-Once Delivery May Not Be What You Want It's hard to get, but that's OK, because you don't want it. Last week, there was a good discussion on lobste.rs about why exactly-once messaging is not possible. The discussion was kicked off with a link to a paper from Patel et al titled Towards In-Order and Exactly-Once Delivery using Hierarchical Distributed Message Queues, which claims to contribute: ... a highly scalable distributed queue service using hierarchical architecture that supports exactly once delivery, message order, large message size, and message resilience. I haven't evaluated the author's other claims in detail, but the claim of exactly once delivery caught my eye. There is no chance of getting two get requests for the same message. When a HTTP message request comes in, a message is sent through HTTP response and the message is deleted at the same time. While I'm not fully satisfied about their at the same time, they don't seem to be claiming to break any fundamental laws here. What I do feel is fundamental, though, is that this definition of exactly once delivery isn't the one that most systems builders would find useful. The effect that most people are interested in is actually exactly-once processing: a message having a particularly side-effect exactly once per message. I like to think about this in terms of redundancy. Fault-tolerant distributed systems deal with all kinds of failures, but it's often practically useful to break them into two categories: node failure and message loss. Node failures can be tolerated with redundancy in space, having multiple copies of a piece of data on multiple nodes. Message loss can be tolerated with redundancy in time, sending the same message multiple times if it doesn't seem to have been received. Replicated databases are redundant in space, and TCP is a great example of redundancy in time. Side note: I stole this characterization from the excellent talk titled Outwards From The Middle of the Maze by Peter Alva