The acks setting on a Kafka producer controls how many broker replicas must confirm they have received a record before the producer treats the send as successful, directly trading off durability against latency.
Key Points: • acks=0 — the producer doesn't wait for any confirmation, giving the lowest latency but risking silent data loss. • acks=1 — only the partition leader must acknowledge the write; data can still be lost if the leader fails before followers replicate it. • acks=all (or -1) — every in-sync replica must acknowledge, giving the strongest durability guarantee at the cost of higher latency. • acks=all should be paired with min.insync.replicas to actually enforce that a minimum number of replicas confirm the write.
Example: A financial transactions producer would use acks=all with min.insync.replicas=2 to make sure a payment record survives a broker crash, while a producer emitting non-critical clickstream metrics might use acks=1 to favor throughput.
Interview Tip: A concise interview answer is:
"The acks setting controls the producer's durability guarantee: acks=0 fires and forgets, acks=1 waits only for the leader, and acks=all waits for all in-sync replicas, so I pick acks=all with min.insync.replicas set appropriately whenever losing a message is unacceptable."