acks
reliabilitydefault: all
type: string (0, 1, or -1/all)
acks controls how many broker acknowledgements the producer waits for before considering a write successful. acks=0: fire-and-forget (no ack, possible data loss). acks=1: leader acknowledges (data loss if leader fails before replication). acks=all/-1: all in-sync replicas acknowledge (no data loss as long as min.insync.replicas is met). acks=all is the default since Kafka 3.0.
Details
acks is the single most important producer configuration for durability.
acks=0 (fire-and-forget): Producer does not wait for any acknowledgement. Records are lost if the broker restarts before writing to disk. Highest throughput and lowest latency. Use only for non-critical metrics, logs, or monitoring data where occasional loss is acceptable.
acks=1 (leader only): Leader writes record to its local log and acknowledges. Followers may not have replicated yet. If the leader fails after ack but before replication, the record is lost (unclean leader election required for recovery). Reasonable for use cases where some loss is tolerable.
acks=all / acks=-1 (all ISR): Leader waits for all in-sync replicas to write the record before sending ack. Combined with min.insync.replicas=2 and replication.factor=3: record is on at least 2 brokers before the producer receives ack. No data loss as long as one ISR member survives. This is the default since Kafka 3.0 and the recommended setting for production.
Loss scenarios: acks=all + min.insync.replicas=1: equivalent to acks=1 (only leader must be in ISR) acks=all + min.insync.replicas=2 + replication.factor=3: safest standard config
Latency impact: acks=0: lowest latency (no wait) acks=1: ~1ms (network RTT to leader) acks=all: ~2–10ms (leader + replication RTT)
Recommended values
| Scenario | Value |
|---|---|
| Maximum durability (payments, orders) | acks=all with min.insync.replicas=2 |
| Balance throughput and durability | acks=1 (acceptable loss risk) |
| Metrics, logs, analytics (loss OK) | acks=0 for maximum throughput |