Kafka Replication Factor: How to Choose, Check, and Change It

Kafka replication factor is the number of brokers that store each topic partition. A factor of three gives each partition one leader replica and two follower replicas. Kafka can then keep serving the partition when one broker fails, provided another eligible replica is current.

More replicas improve tolerance for broker and disk failure. They also consume more storage, network bandwidth, and recovery capacity. The right value depends on your failure domains and durability target, not a universal rule.

Key takeaway

A replication factor of three is a common production baseline. Pair it with rack-aware placement, min.insync.replicas=2, and producers using acks=all. Those settings protect writes inside one cluster. They do not create a historical backup or a second-cluster recovery plan.

What is Kafka replication factor?

Replication factor counts the assigned replicas for each partition. If a topic has 12 partitions and a replication factor of three, Kafka maintains 36 partition replicas in total. Each partition still has its own leader and follower set.

The leader handles normal producer writes. Followers fetch the leader's log and remain candidates for leadership. Kafka can elect a current follower when the leader becomes unavailable.

Replication factor is not the number of acknowledgements required for a write. It is also not the number of Kafka clusters holding the topic. It describes replicas within one cluster.

The factor cannot exceed the number of eligible brokers. A three-broker cluster can use a factor of three. A two-broker cluster cannot place three distinct replicas of the same partition.

For more detail about leaders, followers, high watermarks, and leader election, read Kafka replication explained. This guide focuses on choosing and operating the factor itself.

How to choose a Kafka replication factor

Start with the number of simultaneous broker or failure-domain losses the topic must tolerate. Then check that the cluster has enough brokers, racks, storage, network capacity, and recovery headroom.

Replication factor	Typical fit	Main tradeoff
1	Local development or disposable data	One broker loss makes the partition unavailable and may lose data
2	Small noncritical clusters with tight capacity	Can survive one current replica loss, but maintenance leaves no extra copy
3	Common production baseline	Uses about three times the partition data storage before compression and filesystem effects
4 or more	Data with stricter failure-domain requirements	Higher storage, replication traffic, and recovery load

A factor of three is useful because it leaves room for one broker failure while two current replicas can still acknowledge writes. It also supports maintenance without reducing every partition to its final copy.

That baseline only works when placement matches the risks. Three replicas on three brokers in one rack still share one rack failure. Set broker.rack and keep enough brokers across distinct racks or availability zones. Kafka then spreads a partition across as many configured racks as the factor and topology allow.

Higher factors are not free durability. Every extra follower fetches every record, stores a full partition copy, and may copy large logs during recovery. Model steady-state ingress and the catch-up traffic after a broker returns.

Topics need not all use one factor. Critical event streams may warrant three or more replicas. Rebuildable analytics topics may accept two. Local scratch topics may use one, but a factor of one should not carry data you need to retain.

Replication factor vs ISR, minimum ISR, and acks

Four settings and states form the write-safety chain:

• Replication factor is the number of assigned replicas.
• ISR is the in-sync replica set, the assigned replicas currently caught up enough to remain eligible under Kafka's rules.
• min.insync.replicas is the minimum ISR size required for a successful write when the producer uses acks=all.
• Producer acks decides what acknowledgement the producer waits for.

Consider a topic with replication factor three and min.insync.replicas=2. Its producer uses acks=all.

Current ISR size	Can acks=all writes succeed?	Operational meaning
3	Yes	All assigned replicas are current
2	Yes	One replica is unavailable or behind; redundancy is reduced
1	No	Kafka rejects the write instead of accepting it on the final current replica

acks=all waits for all replicas that are in the current ISR. It does not mean every assigned replica regardless of health. The minimum ISR setting supplies the floor below which Kafka refuses the write.

Without that combination, a factor of three can give less write protection than the number suggests. A producer using acks=1 can receive success after the leader writes the record, before followers confirm it. Replica count alone does not define the acknowledged-write guarantee.

Set the replication factor when creating a topic

Pass the factor to Kafka's topic tool when you create a topic. This example creates an orders topic with 12 partitions and three replicas per partition:

bin/kafka-topics.sh \
  --bootstrap-server kafka-1.example:9092 \
  --create \
  --topic orders \
  --partitions 12 \
  --replication-factor 3 \
  --config min.insync.replicas=2

The command fails if Kafka cannot assign three distinct brokers to every partition. Check broker availability and cluster metadata before treating that as a topic-level error.

Clusters also have defaults for auto-created topics and internal topics. Do not assume those defaults match your application requirement. Prefer explicit topic creation through versioned infrastructure or an operator, then inspect the resulting assignments.

After creation, verify that the replicas span the intended racks. The factor tells you how many copies exist. It does not, by itself, prove that placement covers your chosen failure domains.

Check a Kafka topic's replication factor and health

Use kafka-topics.sh --describe to inspect the factor and each partition's live state:

bin/kafka-topics.sh \
  --bootstrap-server kafka-1.example:9092 \
  --topic orders \
  --describe

A healthy partition with factor three may look like this:

Topic: orders  Partition: 0  Leader: 5  Replicas: 5,6,7  Isr: 5,6,7

Read the fields separately:

• Leader is the broker accepting normal reads and writes for that partition.
• Replicas lists every assigned replica. Its count is the partition's factor.
• Isr lists the assigned replicas currently in sync.

If Replicas contains three brokers but Isr contains two, the configured factor is still three. The partition is under-replicated because one assigned replica is not current. Investigate sustained ISR shrink even though the topic metadata still reports the intended factor.

Brief ISR movement can occur during controlled maintenance. A persistent gap can point to a failed broker, slow disk, constrained network, or a follower that cannot catch up. Check the cause before starting another reassignment.

Change the Kafka replication factor safely

Changing an existing topic's factor requires partition reassignment. Kafka must copy each affected partition to its new broker set or remove an assigned copy. There is no single topic switch that safely chooses all target brokers for you.

First capture the current assignment. Then prepare a JSON plan that lists every affected partition and its complete target replica set. This small example changes only partition 0 of orders from broker 5 to brokers 5, 6, and 7:

{
  "version": 1,
  "partitions": [
    {"topic": "orders", "partition": 0, "replicas": [5, 6, 7]}
  ]
}

Execute the reviewed plan with Kafka's reassignment tool:

bin/kafka-reassign-partitions.sh \
  --bootstrap-server kafka-1.example:9092 \
  --reassignment-json-file increase-replication-factor.json \
  --execute

Kafka prints the current assignment before starting. Save it as your rollback plan. Verify the same target plan until reassignment completes:

bin/kafka-reassign-partitions.sh \
  --bootstrap-server kafka-1.example:9092 \
  --reassignment-json-file increase-replication-factor.json \
  --verify

Do not paste the one-partition sample across a production topic. Inventory all partitions, preserve balanced leadership, select distinct brokers, and respect rack placement. A complete topic change needs an entry for each partition whose assignment will change.

Reassignment copies data across the cluster. Schedule capacity for that traffic, watch request latency and ISR, and apply reassignment throttles when needed. Remove any temporary throttle after verification. Finish by running kafka-topics.sh --describe again and confirming the intended replica and ISR counts.

Reducing the factor also uses reassignment, but it removes copies. Confirm that remaining replicas cover the required failure domains before executing the plan. Never edit Kafka's internal topic assignments casually.

Common replication factor mistakes

Choosing more replicas than the cluster can place

A factor of three needs at least three eligible brokers. Capacity planning must also account for unavailable brokers during maintenance. A barely large enough cluster has little room to recover and rebalance.

Ignoring rack-aware placement

Replica count protects against independent broker loss only when replicas do not share the same larger failure domain. Configure rack identifiers and confirm the actual assignments after creation or reassignment.

Treating replication factor as the write guarantee

An assigned follower may be behind. Producer acknowledgements may also return before followers confirm the record. Review ISR, min.insync.replicas, and producer acks together.

Treating replication as backup

All replicas follow the same live partition history and retention policy. A bad producer write reaches followers. Topic deletion or an operational mistake can affect every live copy. Replica count cannot restore yesterday's valid state.

Replication factor is one protection layer

Use each data-protection mechanism for its intended failure scope.

Protection layer	Main failure scope	What it does not provide alone
Native partition replication	Broker, disk, or rack failure inside one cluster	Cluster-wide recovery or historical restore points
Cross-cluster replication	Cluster or site availability	Rewind before replicated deletion or corruption
Independent backup	Logical data loss and point-in-time recovery	Immediate service failover to a running cluster

The Kafka disaster recovery guide explains how the layers fit into RTO and RPO planning. Kafka backup strategies compares independent storage with replication approaches.

When earlier-state recovery matters, add a tested backup and restore path. OSO Kafka Backup can preserve topic data and consumer group offsets outside the live replica set. See the point-in-time restore guide for the recovery workflow.

Choose replication factor from tolerated failures, placement, and available capacity. Then audit the settings that turn assigned copies into safe writes. Replication factor is essential, but it only covers one boundary.

Frequently asked questions

Frequently asked questions

What is Kafka replication factor?

Kafka replication factor is the number of brokers assigned to store each partition. A factor of three creates one leader replica and two follower replicas per partition.

How do I pick a replication factor in Kafka?

Choose a factor from the broker and failure-domain losses the topic must tolerate. Three is a common production baseline when the cluster has enough brokers, rack-aware placement, and capacity for recovery traffic.

How do I check the replication factor of a Kafka topic?

Run kafka-topics.sh with --describe and count the broker IDs in the Replicas field for each partition. Compare Replicas with Isr to find assigned copies that are not currently in sync.

How do I change the replication factor in Kafka?

Create a reviewed partition reassignment JSON with the complete target broker list for each affected partition. Execute and verify it with kafka-reassign-partitions.sh, then confirm the final replica and ISR counts.

What is the difference between replication factor and ISR?

Replication factor is the assigned number of replicas. ISR is the subset of assigned replicas that are currently in sync and eligible under Kafka replication rules.