> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Producer Acknowledgments Acks and Reliability Guarantees > Explains Kafka producer acknowledgment settings and their impact on durability, latency, throughput, and configuration best practices for preventing data loss. 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. 2. 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) ```properties theme={null} bootstrap.servers=broker1:9092,broker2:9092 key.serializer=org.apache.kafka.common.serialization.StringSerializer value.serializer=org.apache.kafka.common.serialization.StringSerializer acks=all ``` * Console producer (shell) ```bash theme={null} kafka-console-producer.sh --broker-list broker1:9092 --topic my-topic \ --producer-property acks=all ``` * Confluent Python (confluent\_kafka) ```python theme={null} from confluent_kafka import Producer conf = {'bootstrap.servers': 'broker1:9092', 'acks': 'all'} p = Producer(conf) ``` Quick comparison table | `acks` value | Latency | Throughput | Durability risk | When to use | | ------------ | ------- | ---------- | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `0` | Lowest | Highest | High (message loss likely on broker failure) | Best-effort high-throughput use cases where some loss is acceptable | | `1` | Low | High | Moderate (depends on leader stability) | Balanced cases where latency matters and some risk is acceptable | | `all` / `-1` | Highest | Lower | Lowest (strongest durability when ISR configured correctly) | Critical data where durability is required; combine with replication and `min.insync.replicas` | 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.