Exactly-Once in Practice — Idempotency & Retry-Safe Systems

Kafka exactly-once semantics (idempotent producers + transactions) guarantee that consume-transform-produce pipelines within Kafka commit outputs and offsets atomically. Stream processors (Kafka Streams, Flink) extend this with checkpointing and transactional sinks. Workflow engines (Temporal) give durable execution where activities may be retried but workflow state is consistent. None of these make an external HTTP call or email happen exactly once — those still need idempotency keys or dedupe at the destination.

What each 'exactly-once' covers

Mechanism	Scope of exactly-once	External side effects
Kafka idempotent producer	No duplicate writes per partition from producer retries	Not covered
Kafka transactions (EOS)	Read-process-write within Kafka	Not covered
Flink checkpoints + 2PC sinks	Pipeline state + supported sinks	Only transactional sinks
Temporal workflows	Workflow state; activities at-least-once	Activities must be idempotent
Idempotency keys at destination	Specific external effect	Covered

# Kafka producer for EOS pipelines
enable.idempotence=true
acks=all
transactional.id=orders-enricher-1
# consumer side
isolation.level=read_committed

Common pitfalls

Marketing claims of end-to-end exactly-once.
Forgetting read_committed on consumers.
Non-idempotent Temporal activities.

Key points

EOS is scoped to the system
External effects still need idempotency
Check boundaries of every guarantee

Further reading: Apache Kafka: Message delivery semantics

Practice questions

What does isolation.level=read_committed do for Kafka consumers?

Answer

It makes consumers read only messages from committed transactions, hiding aborted transactional writes, which is required for exactly-once pipelines.

In Temporal, which parts are retried and must be idempotent?

Answer

Activities (calls to external systems) can be retried after failures/timeouts, so they must be idempotent; workflow code is replayed deterministically from history.