What do the producer acks settings 0, 1, and all (-1) mean, and how do they trade durability against latency?

## 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.