Kafka producers only write data to the current leader broker for a partition and must specify an acknowledgment (acks) level to determine when a message is considered successfully written.
The default value of acks has changed with Kafka v3.0
  • If using Kafka < v3.0, acks=1
  • If using Kafka >= v3.0, acks=all

​
acks=0 (fire and forget)

When acks=0, producers consider messages “written successfully” immediately after sending, without waiting for broker acceptance. Kafka Producer Acks Setting set to 0 Characteristics:
  • Highest possible throughput
  • Lowest latency
  • No durability guarantees
  • Potential for data loss if broker fails
Use cases:
  • Metrics collection where some data loss is acceptable
  • High-volume logging where speed is more important than reliability
  • Scenarios where losing some messages won’t impact business logic

​
acks=1 (leader acknowledgment)

When acks=1, producers consider messages “written successfully” when the leader broker acknowledges receipt. Kafka Producer Acks Setting set to 1 Characteristics:
  • Balanced throughput and durability
  • Leader response required before considering message sent
  • Replication happens asynchronously in background
  • Risk of data loss if leader fails before replication completes
Use cases:
  • Most common configuration for general-purpose applications
  • Good balance between performance and reliability
  • Suitable when some data loss is acceptable but should be minimized

​
acks=all (full acknowledgment)

When acks=all, producers consider messages “written successfully” when all in-sync replicas (ISR) accept the message. Kafka Producer Acks Setting set to all Characteristics:
  • Highest durability guarantees
  • Lower throughput due to replication requirements
  • Works with min.insync.replicas setting
  • No data loss as long as at least one ISR remains
Use cases:
  • Critical business data that cannot be lost
  • Financial transactions
  • Audit logs and compliance data
  • Any scenario where data durability is paramount
Popular Configurationacks=all and min.insync.replicas=2 provides optimal data durability and allows withstanding the loss of one Kafka broker.

​
Interaction with min.insync.replicas

The min.insync.replicas setting works together with acks=all to control durability:
  • min.insync.replicas=1: Only leader needs to be in-sync (defeats purpose of acks=all)
  • min.insync.replicas=2: Leader + 1 follower must acknowledge (recommended)
  • min.insync.replicas=3: Leader + 2 followers must acknowledge (high durability)

​
Topic durability and availability

For a replication factor of 3: Reads: Available as long as one partition is up and considered ISR Writes:
  • acks=0 & acks=1: Available as long as one partition is up and ISR
  • acks=all:
    • min.insync.replicas=1: Tolerates 2 broker failures
    • min.insync.replicas=2: Tolerates 1 broker failure (recommended)
    • min.insync.replicas=3: Cannot tolerate any broker failures

​
Performance implications

​
Throughput comparison

  • acks=0: Highest throughput (no waiting for acknowledgments)
  • acks=1: Moderate throughput (wait for leader only)
  • acks=all: Lowest throughput (wait for all ISRs)

​
Latency comparison

  • acks=0: Lowest latency (immediate return)
  • acks=1: Moderate latency (leader roundtrip)
  • acks=all: Highest latency (full replication roundtrip)

​
Best practices

​
Production recommendations

  • Use acks=all for critical data that cannot be lost
  • Use acks=1 for general-purpose applications with balanced requirements
  • Avoid acks=0 in production unless data loss is explicitly acceptable

​
Configuration examples

High durability (recommended for critical data): 
acks=all
min.insync.replicas=2
retries=Integer.MAX_VALUE
enable.idempotence=true
Balanced performance and reliability: 
acks=1
retries=Integer.MAX_VALUE
Maximum throughput (use with caution): 
acks=0
retries=0
Data loss scenarios
  • acks=0: Data loss if producer fails to send or broker is down
  • acks=1: Data loss if leader fails before replication
  • acks=all: Data loss only if all ISRs fail simultaneously