Kafka producer config
Kafka acks: 0 vs 1 vs all
acks sets how many replicas must have a record before the Kafka producer counts the send as successful. acks=0 waits for nothing, acks=1 waits for the partition leader only, and acks=all (the default since Kafka 3.0) waits for every replica in the ISR. Only acks=all, with min.insync.replicas of 2 or more, survives losing the leader without losing acknowledged records.
- Config
acks(producer)- Default
- all
- Valid values
- 0, 1, all (-1 means the same as all)
- Reference
- Apache Kafka documentation for
acks
Values
acks=0The producer does not wait for any response. Lowest latency, no retries on errors it never hears about, and records can be lost without anyone knowing.acks=1The leader answers once the record is in its own log. A record that the leader acknowledged but no follower copied yet is lost if the leader fails.acks=The leader answers once every replica in the ISR has the record, and only if the ISR has at least min.insync.replicas members; otherwise the write fails with NOT_ENOUGH_REPLICAS.all
What it does
A produce request goes to the partition leader, and followers copy the record by fetching from it. acks decides at which point of that process the leader answers the producer. With acks=all the answer comes when the record is below the high watermark, which also means consumers can read it. Idempotence requires acks=all, so setting acks to 0 or 1 turns idempotence off unless it was enabled explicitly, in which case the producer fails with a ConfigException.
The trade-off
Each step up costs latency: acks=1 adds the leader write, acks=all adds a follower fetch round. In return, acks=all with min.insync.replicas=2 guarantees that an acknowledged record exists on at least two brokers. The catch is availability: when the ISR shrinks below min.insync.replicas, acks=all producers are refused while acks=1 producers keep writing, with only the leader holding their records.
Advice
- Keep acks=all for any data you cannot lose, and set min.insync.replicas=2 on topics with replication.factor=3.
- Use acks=1 or 0 only for data where losing some is acceptable, such as metrics or logs, and where the latency matters.
- Raise throughput with linger.ms, batch.size and compression rather than by lowering acks.
See it in the simulator
- Kafka acks=0 vs acks=1 vs acks=all on a degraded ISR (acks trade-off) Step 4: acks=all produce blocked - NotEnoughReplicas Open at this step: Kafka acks=0 vs acks=1 vs acks=all on a degraded ISR
- Kafka acks=1 data loss: min.insync.replicas does not help (acks=1 durability gap) Step 5: New leader at LEO 0 - record lost Open at this step: Kafka acks=1 data loss: min.insync.replicas does not help
- Kafka producer acks=0: fire and forget, silent data loss (acks=0: fire and forget) Step 4: Leader died before O2 replicated · O2 lost silently Open at this step: Kafka producer acks=0: fire and forget, silent data loss