---
title: "Kafka max.in.flight.requests.per.connection explained"
description: "What max.in.flight.requests.per.connection does in Kafka, why above 1 can reorder retries without idempotence, and why 5 is safe with it. Simulated live."
url: https://monedula.dev/kafka-simulator/configs/max-in-flight-requests-per-connection/
---

# max.in.flight.requests.per.connection and message ordering

Producer config · default 5 · Apache Kafka 4.3.

max.in.flight.requests.per.connection is how many produce requests a producer may have sent on one connection without an answer yet (default 5). Without idempotence, a value above 1 lets a retried batch land after a later one, reordering the partition. With idempotence on, the broker keeps order for up to 5 in-flight requests, so the default is both fast and ordered.

## At a glance

- Config: `max.in.flight.requests.per.connection` (producer)
- Default: 5
- Valid values: 1 or more; 5 or less with idempotence on
- Reference: [Apache Kafka documentation](https://kafka.apache.org/43/configuration/producer-configs/#producerconfigs_max.in.flight.requests.per.connection)

## What it does

The producer pipelines requests: it can send the next batch to a broker before the previous one is acknowledged. When a request fails with a retriable error and is sent again, the requests behind it may already have been written. An idempotent producer numbers every batch per partition, and the broker rejects a batch that arrives out of sequence so the producer can resend in order; the broker remembers the last 5 batches of each producer, which is where the limit of 5 comes from. A producer without idempotence has no such check, so a retry can append after a later batch.

## The trade-off

More requests in flight means more throughput on a high-latency link, because the producer does not wait a full round trip per batch. Setting it to 1 is the old way to keep order without idempotence, at the cost of that pipelining. Above 5, idempotence is no longer possible: if enable.idempotence was not set explicitly it is turned off without a word, and if it was set to true the producer fails with a ConfigException.

## Advice

- Keep the default of 5 with idempotence on (the default since Kafka 3.0): order and no duplicates, with pipelining.
- Only drop it to 1 if idempotence must stay off, and accept that retries can still write duplicates.
- Do not raise it above 5 for throughput; raise linger.ms or batch.size instead.

## See it in the simulator

- [Kafka max.in.flight.requests.per.connection and ordering](https://monedula.dev/kafka-simulator/scenarios/max-in-flight-ordering/) (Out-of-order detection and max.in.flight), step 5: A's retry lands at offset 2 - REORDER. A's retry finally appends at offset 2. The log is [A, B, A]: A was produced before B, yet its retried copy sits AFTER B. max.in.flight > 1 + idempotence off reordered the log (and, being non-idempotent, also duplicated A). [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=01.3.4&t=4)

## Related configs

- [Kafka enable.idempotence: no duplicates on retry](https://monedula.dev/kafka-simulator/configs/enable-idempotence/)
- [Kafka acks: 0 vs 1 vs all explained](https://monedula.dev/kafka-simulator/configs/acks/)
- [Kafka linger.ms: batching latency vs throughput](https://monedula.dev/kafka-simulator/configs/linger-ms/)