High-performance, exactly-once, failure-oblivious distributed programming (2018)

Exactly once processing is not possible in distributed systems. Anyone that tries to sell that snake oil is dishonest and anyone who buys it should not be making purchasing decisions. The definition and requirement of idempotent processing means systems must be able to handle messages delivered more than once, which irrefutably proves there is no such thing as exactly once.<p>Even within centralized, monolithic systems with no outside interaction, laws of physics and reality still apply - a pull on the cord, an earthquake, a flooding or a myriad of other things may interrupt message processing resulting in either exactly zero or more times a message will be processed even if the message were being processed within the confines of an embedded micro-controller using hand crafted assembler code.

Kafka exactly-once semantics addresses the main issue of the article I think.<p>It&#x27;s now relatively simple for a developer to implement a system with exactly once guarantee as long as you take care of the world that is not inside a Kafka transaction (integrations with third parties and such), which is still not super easy sometimes, but less so then the distributed transaction that will happen inside Kafka.<p>Kafka hides the complexity really well from my use of it so far is very reliable with the &quot;new&quot; semantics.

I&#x27;ve been recently reading the papers coming out of the Berkley Disroderly Lab -- Bloom(L) languages, lattices, composing eventually-consistent, coordination-free systems. It&#x27;s interesting to read this article with that lens. There are some properties that are similar, but this one looks like it is designed to let people continue programming the way they are at the cost of increased coordination with other systems.<p>The idea of a replayable log seems to be able to convert a disordered sequence of events into something that is ordered. Whereas, the Bloom(L) stuff constructs algorithms that only requires partial order. An event stream can be disordered because the functions being used are monotonic, and the compositions of the data structure uses operators that are commutative, associative, and idempotent. (Thus, there is no requirement for exactly-once guarantee, or an ordered event stream).

&gt; Many cloud service designs today rely on durable queues, such as Event Hub or Kafka.<p>AFAIK nowhere in the Kafka documentation does it use the term &quot;queue&quot;, and unless you only have one consumer per consumer group it&#x27;s impossible to guarantee FIFO behavior. Maybe call me a nitpicker but I&#x27;ve seen this &quot;queue&quot; language lead to completely wrong assumptions about kafka.