In distributed systems, servers fail. To protect your data, Apache Kafka replicates messages across multiple brokers. But when you write a message, how do you know if it is safely stored? This is controlled by the **acks** (acknowledgment) setting on your producer.

Tuning the acks configuration is one of the most critical decisions you will make. It represents a fundamental trade-off: **How much performance are you willing to sacrifice for data durability?** Let's explore the three settings and their impacts.

Visual Guide of acks=0, acks=1 and acks=all comparison
Real-World Analogy: Mailing an Important Document

Imagine sending a contract to an office building:

  • acks=0 (No receipt): You drop the contract in a regular mailbox. You don't wait for confirmation. If the mailbox catches fire, the contract is lost, but your sending process is instant.
  • acks=1 (Recipient receipt): You deliver it to the office lobby receptionist. You wait for them to sign a slip saying, "I have it." However, if the receptionist loses it before filing it in the archive cabinet upstairs, it's lost.
  • acks=all (Certified receipt): You wait at the lobby until the receptionist passes the contract to all office departments, who review, stamp, and archive it. You only leave when they all sign off. It takes longer, but the contract is completely secure.

The Three ACKs Settings

1. acks = 0 (Fire and Forget)

The producer writes the message to the network socket and immediately reports a successful write. It does not wait for any acknowledgment from the broker.

  • Performance: Maximum throughput and lowest latency.
  • Risk: Highest data loss risk. If the broker is down or the network fails, the producer will never know.
  • Use Case: IoT sensor readings, application metric logs where losing a few lines doesn't matter.

2. acks = 1 (Leader Acknowledgment)

The producer waits for the partition's leader broker to write the record to its local disk and acknowledge the write. It does not wait for follower brokers to copy the message.

  • Performance: Good balance of throughput and safety.
  • Risk: Moderate. If the leader broker acknowledges the write and immediately crashes before its followers copy the message, that message is lost.
  • Use Case: General application communications, social media updates.

3. acks = all (or -1) (Full Quorum Acknowledgment)

The producer waits for the partition leader and all active **In-Sync Replicas (ISR)** to write the record to disk and acknowledge the write.

  • Performance: Lowest throughput and highest latency due to network consensus.
  • Risk: Zero data loss (provided you have multiple replicas configured).
  • Use Case: Financial transactions, banking systems, billing logs.

Production Safety: The min.insync.replicas Rule

Setting acks=all only protects you if there are active followers. If your replication factor is 3, but 2 followers crash, a replication factor of 1 remains. If acks=all writes to the single remaining broker, a crash will still lose data.

To prevent this, pair acks=all with min.insync.replicas = 2 (set at the broker or topic level). This forces Kafka to reject writes with an exception if fewer than 2 active replicas are online, protecting your data integrity.

Conclusion

There is no single "best" acks setting. For logs and telemetry, choose acks=0 or acks=1 to maximize speed. For payment engines and system audits where data loss is unacceptable, configure acks=all combined with a strong min.insync.replicas policy.