min.insync.replicas protects write durability by requiring a minimum number of synchronized partition replicas to acknowledge each write. An in-sync replica has caught up with the leader; lagging replicas do not count. section 2.3.1 section 2.3.2
The setting trades availability for resilience. If the in-sync count falls below the configured value, producers receive an exception instead of treating the write as successful. section 2.3.1 section 2.3.2
Use the setting with the replication factor as a single durability decision:
- A replication factor of 3 with min.insync.replicas set to 2 requires two fully caught-up replicas, including the leader, before accepting a write. section 2.3.2
- The property is configured during topic creation and otherwise inherits the broker-level default, which is 1 unless overridden. section 2.3.2
- Higher minimums improve protection against replica loss but can reject writes when brokers fail or replication falls behind. section 2.3.1 section 2.3.2
Customer 360 topic configuration
A three-broker Customer 360 cluster uses replicas: 3 and min.insync.replicas: 2 for customer profiles and transactions. Each write therefore requires acknowledgment from at least two synchronized replicas. section 2.3.3
asyncapi: 3.0.0
info:
title: Customer 360 Project
version: 1.0.0
description: >
This project aims to aggregate data from various sources, providing a
comprehensive view of customer information.
channels:
customerProfile:
description: Storing profile information of customers.
address: CUSTOMER_PROFILES
bindings:
kafka:
partitions: 9 #1
replicas: 3
topicConfiguration:
min.insync.replicas: 2 #2
transactions:
description: Information about customer transactions.
address: TRANSACTIONS
bindings:
kafka:
partitions: 9
replicas: 3
topicConfiguration:
min.insync.replicas: 2
Inspect the AsyncAPI listing showing min.insync.replicas: 2 alongside nine partitions and three replicas for two Kafka channels. section 2.3.3
