I'm the same 'mjb' from the linked lobste.rs thread. If anybody is interested I expanded that comment into a blog post here: <a href="http://brooker.co.za/blog/2014/11/15/exactly-once.html" rel="nofollow">http://brooker.co.za/blog/2014/11/15/exactly-once.html</a><p>The core problem here is making the act of writing down that you've done something atomic with doing the actual thing. If you can solve that problem, exactly-once processing is easy. If you can ignore that problem, for example because doing the thing is idempotent, exactly-once processing is easy. In the real world, however, it can be really difficult to solve these problems in general and very specific (and often 'incorrect') solutions are used. OP's post talks about a bunch of those, which is very useful.<p>Very often, though, real-world systems settle for 'at least once' or 'at most once' and find out-of-band ways to handle the missing or duplicate messages. Whether this is practical or not depends on the message rate, and the cost of getting it wrong.
Although indirectly related, the comments in <a href="https://issues.apache.org/jira/browse/SAMZA-390" rel="nofollow">https://issues.apache.org/jira/browse/SAMZA-390</a> are also interesting reading (hi Ben!).<p>The Kafka/Samza ecosystem is coming alive with tons of neat ways to interacting with streaming data. For example, take a look at <a href="https://github.com/milinda/Freshet" rel="nofollow">https://github.com/milinda/Freshet</a>
Some caveats about Kafka replication are discussed here: <a href="https://aphyr.com/posts/293-call-me-maybe-kafka" rel="nofollow">https://aphyr.com/posts/293-call-me-maybe-kafka</a>.<p>It is important to include these in the "exactly-once" discussion... (hard to be exactly-once if messages are lost broker-side).<p>Also, great discussion from Coda Hale about "CA" systems here: <a href="http://codahale.com/you-cant-sacrifice-partition-tolerance/" rel="nofollow">http://codahale.com/you-cant-sacrifice-partition-tolerance/</a>