Delivery Semantics & Exactly-Once

Kafka transactions make produce-plus-offset-commit atomic within Kafka for exactly-once between topics, but because they cannot span a database you use the transactional outbox to make a DB write and a Kafka publish reliable together.

The idempotent producer deduplicates the client's retransmissions within one producer session, not two separate sends from your code -- for application-level duplicates you need your own idempotency key and a dedup store.

Kafka transactions are atomic only within Kafka, so for atomicity across a database write and a Kafka publish you use the transactional outbox -- write the business row and an outbox row in one local DB transaction, then a relay publishes the outbox at least once with an idempotency key.

Exactly-once is idempotent writes plus a transaction that atomically commits output records and input offsets together, with a transaction coordinator, commit markers, and producer-id-and-epoch fencing stopping duplicates and zombies.

A crash before commit means those records are reprocessed on resume, which is at-least-once, so you disable auto-commit, commit only after successful processing, and make processing idempotent.

Guaranteed delivery is a stack: acks=all plus min in-sync replicas plus idempotence plus retries on the producer, manual commit after processing with read-committed on the consumer, and a dead letter queue for the unprocessable, all working together.

Idempotence stops retry duplicates on one partition in one session; transactions add atomic all-or-nothing writes across many partitions plus atomic read-process-write with offsets.

Idempotent producers remove retry duplicates on the write path, which is the essential first building block of end-to-end exactly-once.

The AckMode is when the offset bookmark moves, and committing only after successful processing is what makes delivery at-least-once.

At-most-once may lose but never duplicate, at-least-once may duplicate but never lose, and exactly-once does neither.