Suppose a temperature sensor sends a reading every millisecond. If only the current value matters, losing an occasional reading may be preferable to resending old data. Kafka’s producer setting `acks=0` fits that trade-off: the producer sends a message without waiting for a broker acknowledgment. It gets no confirmation that the message arrived or was persisted. section 5.1.1
With no acknowledgment to wait for, this strategy offers the highest performance of the ACK options described here, but the lowest reliability. It provides at-most-once delivery: a message may never arrive, while the producer does not resend it because an ACK was lost. The comparison to UDP describes the lack of delivery feedback; Kafka still uses TCP for transport. section 5.1.1 section 5.1.3
$ kafka-console-producer.sh \
--topic products.prices.changelog \
--bootstrap-server localhost:9092 \
--producer-property acks=0
Set `--producer-property acks=0` on `kafka-console-producer.sh` to try this behavior with a topic. section 5.1.1
A send that appears trouble-free is not proof that a consumer can read the message. In a test where a topic required two in-sync replicas but only one remained, a message sent with `acks=0` did not initially appear in the consumer. Once the stopped brokers returned and caught up, it became readable. For important data, prefer an acknowledgment strategy that confirms persistence: `acks=1` confirms receipt by the leader, while `acks=all` waits for the in-sync replicas. section 5.1.2 section 5.1.1
