What do the producer acks settings 0, 1, and all (-1) mean, and how do they trade durability against latency?
answer
- 0 = fire-and-forget
- 1 = leader only
- all/-1 = full ISR
- durability up, latency up
- all = committed, 1 = written at leader
basics
~20 sacks=0 means the producer never waits for acknowledgement (fastest, can lose data). acks=1 waits only for the leader to write the record. acks=all waits for the leader plus all in-sync replicas, giving the strongest durability but the highest latency.
solid answer
~40 sThe producer config `acks` controls how many broker acknowledgements a producer waits for before considering a send successful. `acks=0`: fire-and-forget, the producer doesn't wait at all and assumes success the moment the record leaves the client buffer — lowest latency, no delivery guarantee, records lost on any failure. `acks=1`: the leader replica writes the record to its log and acknowledges immediately, without waiting for followers — moderate latency, but data is lost if the leader fails before a follower replicates it. `acks=all` (alias `acks=-1`): the leader waits until all replicas in the in-sync replica set (ISR) have replicated the record before acknowledging — highest latency, strongest durability. With idempotence enabled (default in modern clients), `acks=all` is the recommended setting for no data loss.
go deeper
Memorize the three values and the durability/latency direction: 0 fastest/least safe, all slowest/safest.
Explain the leader-crash data-loss window under acks=1 and that all means the ISR, not all replicas.
Connect acks=all to committed vs leader-written semantics and the high watermark, and to idempotence requiring acks=all.
Frame acks as one knob in a durability budget alongside min.insync.replicas, replication.factor, and unclean.leader.election for an org-wide reliability standard.
## What `acks` is In Apache Kafka, a producer sends records to a **partition**, which is replicated across several **brokers**. One broker is the **leader** for that partition (handles all reads/writes); the others are **followers** that copy the leader's log. The set of replicas currently caught up to the leader is the **in-sync replica set (ISR)**. The producer config `acks` (set on `ProducerConfig.ACKS_CONFIG`) decides how many acknowledgements the producer waits for before its `send()` future completes successfully. ### `acks=0` — fire and forget The producer does **not** wait for any response from the broker. It considers the record sent as soon as it is written to the client's socket buffer. Lowest latency and highest throughput, but **any** failure (network drop, broker down, leader change) silently loses the record. Retries are meaningless because the producer never learns of failures. Use only for tolerable-loss telemetry/metrics. ### `acks=1` — leader acknowledgement The **leader** writes the record to its local log and immediately acknowledges, **without** waiting for followers. If the leader crashes after acknowledging but before a follower replicated the record, that record is **lost** — a classic window of data loss. Good latency, partial durability. ### `acks=all` (a.k.a. `acks=-1`) — full ISR acknowledgement The leader waits until **every replica in the ISR** has fetched and appended the record before acknowledging. Combined with `min.insync.replicas` this gives a tunable durability floor (see follow-ups). This is the only setting that guarantees no acknowledged record is lost as long as at least one ISR member survives. It costs an extra replication round-trip of latency. ### Important nuance: committed vs written A record acknowledged under `acks=all` is **committed** — visible to consumers and durable across the ISR. Under `acks=1` it is merely **written at the leader** and only becomes committed once followers catch up. Consumers only ever read up to the **high watermark** (the offset replicated to all ISR members), so they never see uncommitted records regardless of `acks`. ### Edge cases - With idempotent producers (`enable.idempotence=true`, default since 3.0), Kafka **requires** `acks=all`; setting `acks=0/1` with idempotence throws a config error. - `acks=all` does **not** mean 'all replicas' — it means all **in-sync** replicas. If the ISR has shrunk to just the leader, `acks=all` behaves like `acks=1` unless `min.insync.replicas` forbids it.
- Why is acks=1 still vulnerable to data loss?The leader acknowledges before followers replicate. If the leader crashes during that window and a follower without the record becomes the new leader, the record is permanently lost.
- Does acks=all wait for all replicas or all in-sync replicas?All in-sync replicas (the ISR), not all assigned replicas. A replica that has fallen behind is removed from the ISR and isn't waited on.
saying these in an interview costs you the question
- Saying acks=all waits for every assigned replica regardless of ISR membership.
- Claiming acks=0 supports retries or delivery guarantees.
- Confusing acks=2 as a valid value — only 0, 1, and all/-1 exist.
- Saying acks controls how many partitions are written, not replicas.