Scenario 01.1.2 · acks=1: leader-only ack
Kafka producer acks=1: acknowledged by the leader only
The producer is acked as soon as the leader appends - without waiting for the followers. Faster than acks=all; the record isn’t replicated yet.
Run this scenario in the playgroundIdle · producer ready (acks=1). t+0.000s
Three replicas, a producer configured acks=1.
Open at this step: step 1, Idle · producer ready (acks=1)Acked on the leader · followers not caught up. t+0.900s
With acks=1 the producer is acknowledged (‘ok’) the moment the LEADER appends O1 - LEO is 1 but the high watermark is still 0 because the followers haven't fetched yet. acks=1 does not wait for replication.
Open at this step: step 2, Acked on the leader · followers not caught upFollowers caught up · HW advances. t+1.500s
The followers replicated O1 and the high watermark advanced to 1. acks=1 didn't wait for this step - faster than acks=all, but if the leader had died first, O1 could have been lost (see acks=1 durability gap).
Open at this step: step 3, Followers caught up · HW advancesWhat you start with
With acks=1 the producer is acknowledged the instant the leader writes the record to its own log, without waiting for the followers to replicate it. A deliberately slow replica fetch makes the gap visible: O1 is acked with LEO 1 while the high watermark still sits at 0, then advances once the followers catch up.
Step by step
- Idle · producer ready (acks=1) t+0.000s Three replicas, a producer configured acks=1. Open at this step: step 1, Idle · producer ready (acks=1)
- Acked on the leader · followers not caught up t+0.900s With acks=1 the producer is acknowledged (‘ok’) the moment the LEADER appends O1 - LEO is 1 but the high watermark is still 0 because the followers haven't fetched yet. acks=1 does not wait for replication. Open at this step: step 2, Acked on the leader · followers not caught up
- Followers caught up · HW advances t+1.500s The followers replicated O1 and the high watermark advanced to 1. acks=1 didn't wait for this step - faster than acks=all, but if the leader had died first, O1 could have been lost (see acks=1 durability gap). Open at this step: step 3, Followers caught up · HW advances
The takeaway
acks=1 trades a window of durability for latency: at ack time the record lives only on the leader, so the high watermark (and any consumer) trails until the followers replicate it.
Configs in this scenario
-
acksHow many replicas must have a write before the producer counts it as sent: 0 (none), 1 (the leader only) or all (every in-sync replica, the default, and required for idempotence). How acks works
Embed this scenario
Paste this into a blog post, a course page or your team's docs. The scenario plays inside your page, and the link under it points readers to this walkthrough.
<iframe src="https://monedula.dev/kafka-simulator/embed/?scenario=01.1.2" title="Kafka Simulator: acks=1: leader-only ack" width="100%" height="520" style="border:1px solid #d0d0d0;border-radius:8px" loading="lazy"></iframe>
<p><a href="https://monedula.dev/kafka-simulator/scenarios/acks-1-leader-only/">Kafka producer acks=1: acknowledged by the leader only</a></p> Further reading
More in Producers & EOS
- Kafka producer acks=0: fire and forget, silent data loss
- Kafka acks=0 vs acks=1 vs acks=all on a degraded ISR
- Kafka acks=1 data loss: min.insync.replicas does not help
- Kafka linger.ms vs batch.size: when the producer sends
- Kafka producer partitioners: keyed, round-robin and sticky
- Kafka compression.type: fewer, larger producer batches
- Kafka buffer.memory and max.block.ms: producer backpressure
- Kafka idempotent producer: retrying NOT_ENOUGH_REPLICAS
- Kafka enable.idempotence=false: a retry writes a duplicate
- Kafka idempotent producer dedup vs a plain producer
- Kafka max.in.flight.requests.per.connection and ordering