Kafka advertises exactly-once. Teams read that and stop writing idempotent consumers. Then the duplicates arrive anyway.
The guarantee is real, and it is narrower than the phrase suggests. Inside Kafka a transaction wraps read, process and write: records are consumed from one topic, transformed, produced to another, and the offsets are committed atomically with the output. Either the output and the offset both land, or neither does.
Underneath, each producer gets an ID and a sequence number per record. A retried produce carries the same sequence number, so the broker discards the duplicate instead of appending it. Consumers have to set isolation.level=read_committed, or they will read records from transactions that were later aborted.
All of it ends at Kafka's boundary. A database write, a payment API call, an email, any external service — the transaction cannot reach them, and every one of them can still happen twice.
Which puts idempotency back where it always was: in the handler, keyed on something stable like the event ID.
A guarantee is only as wide as the system that issues it. At its edge, we're back to designing for things happening twice.