Producer Acknowledgments

Understanding Kafka's acks=0, acks=1, and acks=all settings for durability vs latency trade-offs.

Read this as What durability proof does the producer wait for?
Failure Trap
Assuming leader acknowledgment means replicated durability.
Decision Rule
Use acks=all with min.insync.replicas for important events; relax only when loss is cheaper than latency.
Kafka producer acknowledgment modes A producer sends a message to a partition leader, which replicates it to follower brokers. The acks setting controls when the write is confirmed: acks=0 confirms immediately (fastest, may lose data), acks=1 waits for the leader only (durable on the leader, lost if the leader fails before replicating), and acks=all waits for every in-sync replica (slowest, fully durable). The final step compares what each setting loses when the leader crashes. Leader, Followers, ISR Producer writes Leader Partition 0 L Follower 1 replica Follower 2 replica ISR = Leader + F1 + F2 acks=0 — Fire & Forget Producer done ✓ Leader ? Follower 1 Follower 2 Latency ~1ms May lose data acks=1 — Leader Confirms Producer waiting… ACK Leader ✓ Follower 1 not yet Follower 2 not yet ~5-10ms Lost if leader dies acks=all — Every ISR Acks Producer waiting… ACK Leader ✓ Follower 1 ✓ Follower 2 ✓ ~20-50ms Fully durable ✓ If the Leader Crashes… acks=0 LOST Never confirmed acks=1 MAYBE LOST On leader only acks=all SAFE ✓ A follower has it More acks = more durable, more latency
1 / ?

Producer, Leader, and Followers

Every Kafka partition has one leader that handles all reads and writes, and multiple followers that replicate the data.

The In-Sync Replicas (ISR) are followers that are caught up with the leader. The acks setting controls when the producer considers a write successful.

  • Leader handles all writes
  • Followers replicate asynchronously
  • ISR = replicas not lagging behind

acks=0: Fire and Forget

With acks=0, the producer doesn't wait for any acknowledgment. It sends the message and immediately considers it successful — whether or not it actually arrived.

Use this for metrics, logs, or anything where occasional loss is acceptable.

  • Fastest possible latency (~1ms)
  • No durability guarantee
  • Use case: High-volume, loss-tolerant data

acks=1: Leader Acknowledgment

With acks=1, the producer waits for the leader to acknowledge. The message is persisted on the leader's disk before ACK.

Risk: If the leader crashes BEFORE replicating to followers, the message is lost.

  • Moderate latency (~5-10ms)
  • Durable on leader
  • Risk: Leader failure before replication

acks=all: Full ISR Replication

With acks=all (or acks=-1), the producer waits for ALL in-sync replicas to acknowledge. The message is replicated to every ISR member before the ACK returns.

This is the only setting that guarantees durability if any single broker fails.

  • Highest latency (~20-50ms)
  • Full durability guarantee
  • Use case: Financial transactions, critical events

What Happens on Leader Failure?

The real test is failure:

  • acks=0: Message may never have arrived. Lost.
  • acks=1: Message was on leader but not replicated. Maybe lost.
  • acks=all: Message is on multiple replicas. New leader has it. Safe.

Most production uses acks=all with min.insync.replicas=2.