← Back to Kafka

Kafka — acks=0/1/all

KafkaSeniorkafka

The Question

What do acks=0, acks=1, and acks=all mean in Kafka?

What a Strong Answer Covers

  • producer setting
  • all three levels
  • ISR" not "consumers/brokers

Senior-Level Answer

Kafka's `acks` producer configuration controls how many broker acknowledgements the producer requires before considering a write successful. It is the primary knob for trading off durability against throughput and latency.

**acks=0 (fire-and-forget)**: The producer sends the message and does not wait for any acknowledgement from the broker. The message is written to the network buffer and the producer immediately continues. This provides the absolute lowest latency and highest throughput, but offers zero durability guarantee—if the broker crashes before writing to disk, the message is silently lost. Appropriate for high-volume metrics or telemetry where occasional data loss is acceptable.

**acks=1 (leader ack)**: The producer waits for acknowledgement from the partition leader only. The leader writes the message to its local log and responds. This is the default in many Kafka client libraries. It provides a reasonable durability guarantee under normal conditions, but there is a data loss window: if the leader crashes after acknowledging but before the message is replicated to followers, a newly elected follower will not have the message and it will be lost. Latency is one round trip to the leader. Suitable for use cases where occasional loss on leader failure is tolerable.

**acks=all (acks=-1)**: The producer waits for the partition leader to receive acknowledgements from all in-sync replicas (ISR) before responding. The ISR is the set of replicas that are fully caught up with the leader within `replica.lag.time.max.ms`. A message acknowledged with acks=all is durable against any single broker failure (and against multiple failures if the ISR has sufficient members). This configuration must be paired with `min.insync.replicas` (broker/topic config) to prevent the ISR from shrinking to just the leader—setting `min.insync.replicas=2` with a replication factor of 3 ensures at least two brokers must acknowledge. Latency is one round trip plus the replication lag to the slowest ISR member. Required for financial transactions, order processing, and any use case where message loss is unacceptable.

**Interaction with retries and idempotency**: With acks=1 or acks=all, network timeouts can cause duplicate messages if the producer retries a message the broker already committed. Setting `enable.idempotence=true` (Kafka 0.11+) with `acks=all` enables exactly-once semantics at the producer level—the broker deduplicates using a sequence number per producer session.

What Separates a 2/3 from a 3/3

2/3 — Passing but Incomplete

Correctly defines all three ack levels with their durability guarantees and latency implications, and names the data loss scenario for acks=1.

3/3 — Strong Answer

Covers definitions, durability guarantees, the ISR concept, min.insync.replicas interaction with acks=all, and idempotent producers for exactly-once semantics.

Common Mistakes

  • Saying acks=all guarantees no data loss without mentioning min.insync.replicas—if ISR shrinks to 1, acks=all behaves like acks=1.
  • Not explaining what the ISR is when discussing acks=all.
  • Confusing acks with replication factor—replication factor controls how many copies exist; acks controls how many must confirm the write.
  • Not mentioning duplicate message risk on retry and how idempotent producers solve it.

Follow-Up Questions

  • What is the in-sync replica set (ISR) and how does it affect acks=all durability? — ISR = replicas fully caught up within replica.lag.time.max.ms. If ISR = {leader only}, acks=all is equivalent to acks=1—min.insync.replicas prevents this.
  • How does min.insync.replicas interact with acks=all to prevent data loss? — min.insync.replicas=2 means the broker rejects the write if fewer than 2 replicas are in-sync, preventing acks=all from degrading to leader-only acknowledgement.
  • When would you use acks=0 in a production system? — High-volume telemetry, application metrics, or clickstream data where losing a small fraction of events is acceptable and throughput/latency are paramount.
  • How do idempotent producers prevent duplicates when retrying with acks=all? — The broker assigns each producer a PID and tracks sequence numbers per partition. Retransmitted messages with the same sequence number are deduplicated server-side.

Related Questions

  • Kafka — Why Is It Fast
  • Kafka — Consumer Lag
  • Kafka — ISR
  • Kafka — Consumer Group
  • Kafka — Rebalance

Can You Explain This Cold?

Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.

Get Graded — Free Assessment
GrindQuestionsAITechnical interview assessment
TermsPrivacyAbout