Effectively-once

Effectively-once - the honest name for what "exactly-once" systems actually do: deliver effectively once, by delivering at least once and making the duplicates change nothing. The term exists because the industry oversold the other one. Mechanically it is two parts: at-least-once delivery underneath, so nothing is lost, plus an idempotence layer on top, sequence numbers, transactional commits or deduplication by key, so a redelivered event cannot alter state twice. Kafka's own exactly-once machinery, per KIP-98, is built exactly this way: retries underneath, an idempotent producer and transactions on top.

The distinction earns its keep when you audit a vendor claim. Ask where the duplicate is absorbed. If the answer is a specific mechanism with a failure mode you can name, it is effectively-once and real. If the answer is "the framework handles it", keep asking.

Do you need it? You need the concept, because it is what you are buying whenever a box says exactly-once. Ubik's version is spelled out in its docs: at-least-once replay from a checkpoint, made harmless by idempotent, upserted output.