Skip to content

CONCEPT Cited by 3 sources

Producer acks and durability (Kafka)

Definition

In Apache Kafka, producers choose per-session how strong a durability guarantee they want per write via the acks property:

Value Semantics Durability
acks=0 Producer does not wait for a response None — fire-and-forget; record may be lost before it reaches the broker
acks=1 Response when the leader acknowledges (persists to disk) Durable on the leader; lost if leader dies before follower replication
acks=all (default) Response only when all in-sync replicas persist Durable on every ISR member; survives leader failure

Kozlovski's Kafka-101 framing:

"Producers can configure the durability guarantees they want to have during writes via the 'acks' property which denotes how many brokers have to acknowledge a write before the response is returned to the client." (Source: sources/2024-05-09-highscalability-kafka-101)

Composing with min.insync.replicas

acks=all depends on the ISR. If the ISR shrinks to one member (only the leader is in-sync), acks=all silently collapses to the acks=1 guarantee — same wire-level behaviour, weaker guarantee.

min.insync.replicas fixes this by failing the write closed if the ISR drops below the configured threshold:

"To further control the acks=all property and ensure it doesn't regress to an acks=1 property when there is only one in-sync replica, the min.insync.replicas setting exists to denote the minimum number of in-sync replicas required to acknowledge a write that's configured with acks=all." (Source: sources/2024-05-09-highscalability-kafka-101)

This is the canonical Kafka-durability instance of fail-closed semantics — prefer returning an error over silently weakening the contract.

Trade-offs

  • Latency scales with durability: acks=0 < acks=1 < acks=all.
  • Availability conversely: acks=all requires the whole ISR; acks=1 only the leader.
  • acks=all + min.insync.replicas=2 on replication.factor=3 is the canonical "safe default" — can tolerate one replica loss without losing writes and without silent degradation.

acks=1 as the multi-region latency-relief knob

On a multi-region stretch cluster, acks=all means the leader waits for a cross-region Raft quorum on every write — the per-write latency is bounded by cross-region RTT (60-80 ms regional, 150+ ms transoceanic). acks=1 is the canonical first-line producer-side relief knob when this is unacceptable:

"For scenarios where produce latency exceeds requirements, you can configure producers to use acks=1 instead of acks=all. This reduces latency by only waiting for the leader to acknowledge rather than the replication factor and quorum of brokers. However, this comes at the cost of potentially decreased message durability." (Source: sources/2025-02-11-redpanda-high-availability-deployment-multi-region-stretch-clusters)

The trade-off is explicit: acks=1 drops cross-region quorum durability — if the pinned-leader region is lost before replication catches up, the just-acknowledged writes are lost. Composes orthogonally with leader pinning:

  • Leader pinning — topology bias; client hops intra-region; durability preserved.
  • acks=1 — durability relaxation; quorum wait skipped; topology unchanged.

Both applied together yields the lowest-latency configuration possible on a stretch cluster (intra-region leader + leader-only ack) at the cost of region-outage durability. Both off yields the strongest durability (cross-region quorum, cross-region client hops) at the cost of latency.

Seen in

Last updated · 542 distilled / 1,571 read