What do acks=0, acks=1, and acks=all mean in Kafka?
Kafka's `acks` producer configuration controls how many broker acknowledgements the producer requires before considering a write successful. It is the primary knob for trading off durability against throughput and latency.
**acks=0 (fire-and-forget)**: The producer sends the message and does not wait for any acknowledgement from the broker. The message is written to the network buffer and the producer immediately continues. This provides the absolute lowest latency and highest throughput, but offers zero durability guarantee—if the broker crashes before writing to disk, the message is silently lost. Appropriate for high-volume metrics or telemetry where occasional data loss is acceptable.
**acks=1 (leader ack)**: The producer waits for acknowledgement from the partition leader only. The leader writes the message to its local log and responds. This is the default in many Kafka client libraries. It provides a reasonable durability guarantee under normal conditions, but there is a data loss window: if the leader crashes after acknowledging but before the message is replicated to followers, a newly elected follower will not have the message and it will be lost. Latency is one round trip to the leader. Suitable for use cases where occasional loss on leader failure is tolerable.
**acks=all (acks=-1)**: The producer waits for the partition leader to receive acknowledgements from all in-sync replicas (ISR) before responding. The ISR is the set of replicas that are fully caught up with the leader within `replica.lag.time.max.ms`. A message acknowledged with acks=all is durable against any single broker failure (and against multiple failures if the ISR has sufficient members). This configuration must be paired with `min.insync.replicas` (broker/topic config) to prevent the ISR from shrinking to just the leader—setting `min.insync.replicas=2` with a replication factor of 3 ensures at least two brokers must acknowledge. Latency is one round trip plus the replication lag to the slowest ISR member. Required for financial transactions, order processing, and any use case where message loss is unacceptable.
**Interaction with retries and idempotency**: With acks=1 or acks=all, network timeouts can cause duplicate messages if the producer retries a message the broker already committed. Setting `enable.idempotence=true` (Kafka 0.11+) with `acks=all` enables exactly-once semantics at the producer level—the broker deduplicates using a sequence number per producer session.
Correctly defines all three ack levels with their durability guarantees and latency implications, and names the data loss scenario for acks=1.
Covers definitions, durability guarantees, the ISR concept, min.insync.replicas interaction with acks=all, and idempotent producers for exactly-once semantics.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment