Producer Acknowledgements (acks)
Intermediateacks=0 (fire-and-forget), acks=1 (leader ack), acks=all (all ISR ack) — higher acks improve durability at the cost of latency; combine with min.insync.replicas for safety.
Overview
The acks (acknowledgements) configuration is one of the most important producer settings in Kafka. It controls how many broker replicas must confirm a write before the producer considers it successful. This is the primary knob for trading off durability versus throughput and latency. acks=0 gives maximum throughput with zero durability guarantee. acks=1 is a middle ground — the leader confirms receipt but data can still be lost if the leader fails before replicating. acks=all (or acks=-1) is the safest option — the leader only responds after all in-sync replicas (ISR) have persisted the record. Combined with min.insync.replicas, acks=all gives the strongest durability guarantee Kafka offers.
The Three acks Settings Explained
acks=0 — Fire-and-forget. The producer does not wait for any acknowledgement. Maximum throughput, but if the broker crashes after receiving the network bytes, the record is lost with no way to know. Use only for metrics, logs, or data where loss is acceptable.
acks=1 — Leader acknowledgement. The partition leader writes to its local log and responds. Followers replicate asynchronously. If the leader crashes before followers catch up, the newly elected leader may not have the record. Unacknowledged records are lost.
acks=all (acks=-1) — All ISR acknowledgement. The leader waits until every replica in the ISR has written the record before responding. Highest durability — survives leader failure as long as at least one ISR member is alive. Highest latency because of the replication round-trip.
// Producer configuration examples
Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
// --- acks=0: fire-and-forget (metrics, non-critical logs) ---
props.put(ProducerConfig.ACKS_CONFIG, "0");
props.put(ProducerConfig.RETRIES_CONFIG, "0"); // no point retrying — no response anyway
// --- acks=1: leader ack only (moderate durability) ---
props.put(ProducerConfig.ACKS_CONFIG, "1");
// --- acks=all: strongest durability (financial, order events) ---
props.put(ProducerConfig.ACKS_CONFIG, "all"); // or "-1"
props.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE + "");
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, "true"); // auto-sets acks=all + retries
KafkaProducer<String, String> producer = new KafkaProducer<>(props);min.insync.replicas — The Critical Partner
acks=all alone is not enough. If the ISR shrinks to just the leader (all followers are lagging), acks=all is satisfied by a single replica — the same as acks=1. min.insync.replicas (broker/topic config) sets the minimum number of ISR replicas that must acknowledge a write. If fewer replicas are in-sync, the broker rejects the write with NotEnoughReplicasException.
The recommended production combination for critical topics: • replication.factor=3 • min.insync.replicas=2 • acks=all
This tolerates one broker failure while guaranteeing at least two replicas have the record.
# Safe production defaults for a critical topic
kafka-topics.sh --bootstrap-server localhost:9092 \
--create \
--topic payments \
--partitions 12 \
--replication-factor 3 \
--config min.insync.replicas=2
# Or set at broker level in server.properties:
# min.insync.replicas=2
# What happens when ISR shrinks to 1 with min.insync.replicas=2?
# Producer gets: org.apache.kafka.common.errors.NotEnoughReplicasException
# Writes are blocked until a replica rejoins the ISR — this is intentional!
# It's better to block writes than silently accept data that might be lost.
# application.yml — Spring Boot producer defaults
spring:
kafka:
producer:
acks: all
retries: 2147483647
properties:
enable.idempotence: true
max.in.flight.requests.per.connection: 5Key Points to Remember
- 1acks=0 (fire-and-forget), acks=1 (leader only), acks=all (all ISR) — higher acks = higher durability, higher latency.
- 2acks=all alone is not sufficient if the ISR contains only one replica; combine with min.insync.replicas=2 for genuine durability.
- 3The recommended production combination for critical data: replication.factor=3, min.insync.replicas=2, acks=all.
- 4enable.idempotence=true automatically sets acks=all, retries=MAX_INT, and max.in.flight.requests.per.connection=5.
- 5If min.insync.replicas is not satisfied, the broker throws NotEnoughReplicasException — this is a safety guard, not a bug.
- 6For non-critical high-throughput data (analytics, metrics), acks=1 or acks=0 is acceptable to maximise throughput.
Interview Questions
Sign in to ask AriaExplain the three acks settings in Kafka and when you would use each.
What is min.insync.replicas and how does it interact with acks=all?
With acks=all and replication.factor=3, how many broker failures can you tolerate?
What happens to a Kafka producer if min.insync.replicas is not met?
What does enable.idempotence=true do and what settings does it imply?
Ask Aria about Producer Acknowledgements (acks)
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.