Kafka Replication & Leader Election

Question 1

Under acks=all, when is a produced record considered committed?

Accepted Answer

Once every in-sync replica has persisted it to its own log — With acks=all the high-water mark only advances once all in-sync replicas have the record, which is what lets a newly elected leader avoid losing acknowledged writes.

Question 2

Kafka replication provides fault tolerance by…

Accepted Answer

Storing copies of each partition on multiple brokers — Each partition has a replication factor of N: one leader and N−1 followers on different brokers, so data survives broker failures.

Question 3

For each partition, the LEADER replica…

Accepted Answer

Handles all reads and writes for that partition — Clients produce to and consume from the leader; followers fetch the leader's data to stay in sync.

Question 4

FOLLOWER replicas…

Accepted Answer

Pull records from the leader replica to keep their own log up to date — Followers passively replicate the leader's log so one can be promoted if the leader fails.

Question 5

The In-Sync Replicas (ISR) set is…

Accepted Answer

Replicas fully caught up — ISR are replicas within the allowed lag of the leader; only ISR members are eligible to become leader, ensuring no committed data is lost.

Question 6

When a leader fails, a new leader is…

Accepted Answer

Elected from the in-sync replica set so no committed records are lost — Electing from the ISR guarantees the new leader has all committed messages, preserving durability during failover.

Question 7

The producer 'acks' setting acks=all means…

Accepted Answer

Acknowledged once all in-sync replicas confirm the record — acks=all waits for the full ISR, maximizing durability at the cost of higher latency; acks=1 (leader only) and acks=0 trade durability for speed.

Question 8

acks=0 vs acks=all is a trade-off between…

Accepted Answer

Latency vs durability — acks=0 is fastest but can lose data; acks=all is safest but slower. The choice depends on the application's durability requirements.

Question 9

min.insync.replicas controls…

Accepted Answer

The minimum in-sync replica count required to permit acks=all produce requests — If the ISR drops below this, writes with acks=all are rejected — preventing acknowledging data that isn't sufficiently replicated.

Question 10

With replication.factor=3, min.insync.replicas=2, and acks=all, the partition remains fully available for writes after…

Accepted Answer

Losing exactly one broker — One broker can fail and the ISR still has 2 members (≥ min.insync.replicas=2), so acks=all writes keep flowing with no data loss. A second failure drops the ISR to 1, triggering NotEnoughReplicasException — the partition becomes write-unavailable rather than risking silent data loss.

Broker 1

Broker 2

Broker 3

Key insight

A write with acks=all

Test your knowledge

Under acks=all, when is a produced record considered committed?

The short version

In more depth

Kafka Replication & ISR

In-Sync Replicas (ISR)

Failover

Interview Questions

References & Further Reading

Related topics

Love this visualization?