Skip to main content
Hello and welcome back. In this lesson we cover Kafka producer acknowledgments (acks) and how they relate to reliability guarantees. These producer settings determine when a producer considers a send successful — and therefore the trade-off between throughput/latency and data durability. To make this concrete, imagine a producer sending messages to a topic with multiple partitions (for example, partition 0 and partition 1). The key question: when the producer sends a message, does it receive confirmation that Kafka has durably stored that message?
The image illustrates a Kafka message flow, showing how producers send messages to a broker and questioning the acknowledgment process back.
Overview: Kafka producers can request acknowledgments at different levels using the acks setting. The chosen level affects latency, throughput, and the risk of data loss.
  • acks=0
    The producer does not wait for any acknowledgment from the broker. The send is fire-and-forget. This yields the highest throughput and lowest latency, but messages can be lost if the broker fails before persisting them.
  • acks=1
    The producer waits for an acknowledgment from the partition leader only. This guarantees the leader has accepted and appended the record to its local log, but it does not guarantee replication to followers. If the leader fails before followers replicate the message, data loss is possible.
  • acks=all (equivalently acks=-1)
    The producer waits until all in-sync replicas (ISRs) have acknowledged the write. This provides the strongest durability guarantee (assuming the ISR is correctly configured) but increases latency.
The image explains Kafka Producer acknowledgment settings for data writes, detailing the potential for data loss with different acknowledgment levels: "acks=0" (possible data loss), "acks=1" (limited data loss), and "acks=all" (no data loss).
Practical details
  1. acks=1 (leader acknowledgment)
  • Flow: producer sends the record to the partition leader → leader appends to its local log → leader returns acknowledgment to the producer.
  • Implication: producer does not wait for followers to replicate; replication success is unknown to the producer.
  • Risk: if the leader fails after acknowledging the write and before followers have replicated it, the record can be lost.
The image is a diagram illustrating producer acknowledgments and reliability guarantees in Kafka. It shows a producer sending a message to "Broker 1, Partition 01," and receiving an acknowledgment after the data is stored.
  1. acks=all / acks=-1 (all in-sync replicas)
  • Flow: producer sends to leader → leader writes locally and waits until all in-sync replicas have persisted the record → producer receives acknowledgment only then.
  • Implication: strong durability guarantee so long as your replication and ISR configuration are correct.
  • Important knobs: replica count and min.insync.replicas — together they define how many brokers must have a copy before a write is considered successful.
The image illustrates a data flow diagram showing producer acknowledgments and reliability guarantees in a broker-based system with one main partition and multiple replicas, emphasizing limited data loss when "acks=all" is used.
Configuration examples
  • Java (Producer properties)
  • Console producer (shell)
  • Confluent Python (confluent_kafka)
Quick comparison table Guidance and best practices
  • Use acks=0 when minimal latency and maximum throughput are primary, and occasional loss is acceptable (e.g., non-critical telemetry).
  • Use acks=1 for a compromise: good latency with reasonable durability, but accept the risk of leader-only writes.
  • Use acks=all for the strongest durability. Also ensure:
    • You have an appropriate replication factor (≥ 3 is common for production).
    • min.insync.replicas is configured to prevent writes when too few replicas are available.
Choosing the right acks value is a trade-off: higher durability (e.g., acks=all) increases latency, while lower acknowledgment levels improve throughput but increase the risk of data loss. Tune acks together with replication settings and min.insync.replicas to meet your availability and durability requirements.
Summary Kafka producer acks controls when the producer considers a send successful. Pick the value that aligns with your application’s tolerance for latency and data loss, and always consider replication and broker-level settings to enforce the durability you need. That covers producer acknowledgments and reliability guarantees in Kafka. See you in the next lesson.

Watch Video