In Apache Kafka, data is replicated across brokers for fault tolerance.

• Each topic partition has:

  • Leader replica → handles all reads/writes.

  • Follower replicas → replicate data from the leader.

👉 In-Sync Replicas (ISR) = the set of replicas (leader + followers) that have fully caught up with the leader’s data.

• If a follower is lagging too much, it’s removed from ISR.

• Only ISR members are considered safe copies of the data.

🔹 Example

Suppose you have a topic partition with replication factor = 3:

• Broker 1 → Leader

• Broker 2 → Follower

• Broker 3 → Follower

If all are up-to-date, ISR = {Broker 1, Broker 2, Broker 3}.
If Broker 3 falls behind (network/disk issue), ISR = {Broker 1, Broker 2}.

🔹 Why ISR Matters?

• Acknowledgements:

  • If acks=all → Kafka waits for data to be written to all ISR replicas, ensuring durability.

  • If a broker is out of ISR, Kafka doesn’t wait for it.

• Leader Election:

  • If the leader fails, a new leader is chosen only from ISR to ensure no data loss.

🔹 Configurations Related to ISR

1. min.insync.replicas

   • Minimum number of ISR replicas required for a write to be considered successful.

   • Prevents writes if too few replicas are in sync (avoids data loss).

2. acks (producer config)

   • acks=1 → leader only.

   • acks=all → leader + all ISR replicas.

   • acks=0 → no acknowledgement (fast but risky).

🔹 Quick Analogy

Think of ISR like a class attendance register:

• Leader = teacher.

• Followers = students copying notes.

• ISR = students who are up-to-date with the teacher’s notes.

• If a student is far behind, teacher doesn’t rely on him for group work.

🔹 In Short

In-Sync Replicas (ISR) = the set of replicas (leader + followers) that are fully caught up with the leader.

• Used for durability, acknowledgements, and safe leader election.

• Key configs: acks, min.insync.replicas.