Idempotent Sink
A destination where writing the same record twice has the same effect as writing it once, which is what makes end-to-end exactly-once achievable at all.
Exactly-once is frequently described as a property of a stream processor. It is more accurately a property of the whole path, and the processor can only supply half of it: it can guarantee that its internal state reflects each input once, by committing state and offsets together.
The other half is the write to the outside world, and no processor can make that atomic with its own commit. On failure between the two, the record is written and the offset is not, so it will be written again.
An idempotent sink absorbs this. A keyed upsert produces the same row whether applied once or five times. A write conditioned on a sequence number rejects replays. A deduplication table keyed on an event identifier discards the second arrival.
What is not idempotent is the common case: appending to a table, incrementing a counter, sending an email, calling a payment API without an idempotency key. For those, exactly-once is not available and the honest design is at-least-once with downstream deduplication — which is what most systems described as exactly-once actually implement.