I/D/E · Visual explainer

Producer Acknowledgments

Summary

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.
Producer P Leader Partition 0 L Follower 1 P0 replica Follower 2 P0 replica ISR: Leader + F1 + F2 The Replication Setup acks=0: Fire and Forget Producer ✓ Success msg Leader ? No confirmation Latency: ~1ms ⚡ ⚠ May lose messages acks=1: Leader Acknowledgment Producer waiting... msg Leader ✓ ACK ? ? Latency: ~5-10ms ⚠ Risk if leader fails first acks=all: Full ISR Replication Producer waiting... Leader ✓ F1 ✓ F2 ✓ ACK All ISR Confirmed ✓ Latency: ~20-50ms ✓ Fully durable What Happens on Leader Failure? 💥 Leader Crashes acks=0 Message: LOST Never confirmed acks=1 Message: MAYBE LOST If not replicated acks=all Message: SAFE ✓ On followers Choose Based On Your Needs Setting Latency Durability Use For acks=0 ~1ms ⚡ None Metrics acks=1 ~5-10ms Leader Logs acks=all ~20-50ms Full ✓ Payments
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.

What's Next?

Understanding acks helps you configure producers for your durability requirements. Combine with producer batching for throughput, idempotence for exactly-once, and min.insync.replicas for stronger guarantees.