Exactly-Once Semantics
also called EOS, Effectively-Once
The guarantee that each input record affects the output state precisely once, achieved through atomic state-and-offset commits rather than through delivering messages once.
The phrase causes more confusion than any other in streaming, because exactly-once delivery over an unreliable network is impossible — the classic two-generals result — and yet the guarantee is real and useful.
The resolution is that the guarantee is about effect, not delivery. A message may be delivered many times; what the framework ensures is that its contribution to the output and to the processing state is applied once. The mechanism is committing the processed output, the updated state and the consumed offset in a single atomic transaction, so a failure either rolls all three back or commits all three.
The critical limitation, and the one that catches teams in production: the guarantee holds only within the transactional boundary of the system that provides it. The moment your processor calls an external API, sends an email or writes to a database outside the transaction, the guarantee stops at that edge. That side effect can and will happen twice.
Which is why the durable engineering answer remains idempotency at the boundaries — deduplication keys, conditional writes, natural idempotence in the operation. Exactly-once inside the framework plus idempotent effects outside it is the combination that actually holds, and it costs throughput and latency, so it should be chosen where correctness demands it rather than by default.