u/MrDV6

I’m currently learning Kafka, and while learning about ISR (In-Sync Replicas), acks, and min.insync.replicas, I tried to demonstrate the behavior in a local multi-broker setup.

I observed something that doesn’t match my understanding, so I wanted to ask here.

Setup

• 3 Kafka brokers running in Docker

• Topic config:

  • partitions = 3
  • replication.factor = 3
  • min.insync.replicas = 100

Topic description:

./kafka-topics.sh --describe --topic isr-error --bootstrap-server kafka-broker-one:9092

Output:

Topic: isr-error PartitionCount: 3 ReplicationFactor: 3 Configs: min.insync.replicas=100

Partition: 0 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Partition: 1 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Partition: 2 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1

Producer command:

./kafka-console-producer.sh \
  --topic isr-error \
  --bootstrap-server localhost:9092 \
  --command-property acks=all \
  --command-property request.timeout.ms=2000 \
  --command-property delivery.timeout.ms=5000 \
  --command-property retries=0

My understanding

From Kafka documentation and this explanation by Jun Rao (Kafka co-founder / Confluent):

Jun Rao explanation of min.insync.replicas

For writes with acks=all, produce requests should succeed only if:

ISR count >= min.insync.replicas

In my case:

ISR = 3
min.insync.replicas = 100

So:

3 >= 100 → false

Based on this, I expected produce requests to fail immediately with NotEnoughReplicasException.

Actual behavior

• Producing succeeded while all 3 brokers were alive.
• Consumer successfully received the messages.

Only after stopping one broker did produce requests fail with:

org.apache.kafka.common.errors.NotEnoughReplicasException:
Messages are rejected since there are fewer in-sync replicas than required.

Question

Why did Kafka accept produce requests earlier even though ISR (3) was already less than min.insync.replicas (100)?

Why was enforcement triggered only after a broker failure / ISR shrink event?

Am I misunderstanding how min.insync.replicas is enforced, or could this be specific to certain Kafka versions / KRaft / Docker setups?

For context:

• Kafka version: 4.2.0
• Mode: KRaft
• Docker image: apache/kafka:latest

Hey everyone,

A while ago I built a small Spring Boot starter for exception handling because I was tired of rewriting the same exception layer in every project. I published it through JitPack and have been using it across my own applications ever since — consistent API error responses from day one without rewriting the same boilerplate over and over.

That experience made me ask a similar question: why am I rebuilding authentication for every project too?

Over the last few months I built AuthX — an open-source authentication system in Java and Spring Boot:

https://github.com/dhanesh76/AuthX

It currently supports credential authentication, Google and GitHub OAuth2 login, JWT access tokens, refresh token rotation, OTP verification, password reset flows, rate limiting, and human verification.

I'm a final-year CS student. Several months of that time were spent refactoring the project after realising the initial design wasn't going to be maintainable long-term. The current version is the result of multiple iterations rather than a weekend project.

What I'm trying to figure out now is:

As a Spring Boot developer, would you be interested in using authentication as reusable infrastructure the same way you might use a logging, exception-handling, or database library?

Would you rather:

A. Run something like AuthX as a standalone identity service that your application calls over HTTP

or

B. Add a dependency, configure a few properties, and have most of the authentication infrastructure wired into your application automatically through a Spring Boot starter

I'm genuinely looking for feedback before deciding what to build next.

If you've built authentication systems before, I'd love to hear what would make something like this useful enough to adopt — or why you wouldn't.

Postman docs:

https://documenter.getpostman.com/view/45135482/2sBXqNkyDM