Streaming Systems

Idempotent Producers

10 min read

Opening scenario

Your payments service writes a payment-confirmed event to Kafka for every successful charge. Downstream, a notification consumer sends one SMS per event. After a network blip last week, a customer received seven identical "payment confirmed" SMS messages within 30 seconds for a single $89 transaction. The producer code looks reasonable. It calls producer.send(record), waits for the future, and logs on success. You scan the producer config:

acks=all
retries=2147483647
max.in.flight.requests.per.connection=5
enable.idempotence=false

There were no application-level retries. The code called producer.send() exactly once per charge. So where did the seven copies come from?

To explain this, you need to understand three things. First, what the producer's retry path does at the network level. Second, why acks=all doesn't prevent duplicates. Third, what enable.idempotence=true actually changes on the wire.

Why does acks=all not give you exactly-once delivery from the producer to the broker?

You can answer part of this.…

In the full tutorial

  • What does enable.idempotence=true actually change in the wire protocol?
  • What does enable.idempotence=true change about your config defaults?
  • What does an idempotent producer NOT protect against?
  • What does the broker do if it gets a sequence number that's way out of order?
  • Sample producer config and behavior
  • Closing: When to reach for this

Glossary history

Click dotted jargon to save explanations here.