No, the parent is correct. acks=1 can still lose data as the broker can lose topic leadership after write but before replication. Roughly you can think of it a

No, the parent is correct. acks=1 can still lose data as the broker can lose topic leadership after write but before replication. Roughly you can think of it as: - acks=0 - can tolerate only a small (but most common!) subset of failures; better to keep going with the next datum than fail/retry if anything is wrong, stale data might as well be no data or you only need 99% of it anyway; very common for web traffic analysis, hardware sensor data, etc; - acks=1 - can tolerate client, client/broker, or single broker failure as long as client can retry; nice for e.g. API uploads where the client has more work to get onto but also wants to provide some reasonable feedback to the caller; a good default; - acks=-1 - can tolerate client, client/broker, broker/broker, or arbitrary broker failure as long as client can retry; good for events which should absolutely not be lost and small enough to keep locally e.g. "batch job finished", "IDS alerted". "At least once" and "at most once" are more often used to describe consumer commit behaviors than producer.