Can acks=all cause production‑cluster failures when ISR shrinks?

Goal

Produce messages with full durability guarantees while keeping latency acceptable in a multi‑broker Kafka cluster.

Constraints and Uncertainty

The producer is configured with acks=all and a replication factor of 3. In a local single‑broker test the write succeeds quickly, but in production the producer sometimes times out or receives a NotEnoughReplicasException when a follower falls out of the ISR. The cluster also has a min.insync.replicas setting of 2.

It is unclear whether adjusting min.insync.replicas, changing the acks value, or tuning broker timeouts will resolve the issue without compromising durability.

Specific Questions

• What producer configuration can prevent NotEnoughReplicasException while preserving the durability promised by acks=all?
• Does lowering acks to 1 eliminate the timeout problem, and if so, what is the trade‑off in terms of message loss?
• How can broker‑side settings (e.g., replica.lag.time.max.ms) be tuned to reduce ISR churn for a producer using acks=all?