Kafka Configs

acks

clientlowdynamic3.94.14.2

The number of acknowledgments the producer requires the leader to have received before considering a request complete. This controls the durability of records that are sent. The following settings are allowed: `acks=0` If set to zero then the producer will not wait for any acknowledgment from the server at all. The record will be immediately added to the socket buffer and considered sent. No guarantee can be made that the server has received the record in this case, and the `retries` configuration will not take effect (as the client won't generally know of any failures). The offset given back for each record will always be set to `-1`. `acks=1` This will mean the leader will write the record to its local log but will respond without awaiting full acknowledgement from all followers. In this case should the leader fail immediately after acknowledging the record but before the followers have replicated it then the record will be lost. `acks=all` This means the leader will wait for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost as long as at least one in-sync replica remains alive. This is the strongest available guarantee. This is equivalent to the acks=-1 setting. Note that enabling idempotence requires this config value to be 'all'. If conflicting configurations are set and idempotence is not explicitly enabled, idempotence is disabled.

Default: all
Valid range: [all, -1, 0, 1]
Scope: client
Related configs

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

add.partitions.to.txn.retry.backoff.max.ms

brokerhighstatic4.14.2

The maximum allowed timeout for adding partitions to transactions on the server side. It only applies to the actual add partition operations, not the verification. It will not be effective if it is larger than request.timeout.ms

Default: 100
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

add.partitions.to.txn.retry.backoff.ms

brokerhighstatic4.14.2

The server-side retry backoff when the server attemptsto add the partition to the transaction

Default: 20
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

advertised.listeners

brokerhighstatic3.94.14.2

Specifies the listener addresses that the Kafka brokers will advertise to clients and other brokers. The config is useful where the actual listener configuration `listeners` does not represent the addresses that clients should use to connect, such as in cloud environments. The addresses are published to and managed by the controller, the brokers pull these data from the controller as needed. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, the value for `listeners` will be used. Unlike `listeners`, it is not valid to advertise the 0.0.0.0 meta-address. Also unlike `listeners`, there can be duplicated ports in this property, so that one listener can be configured to advertise another listener's address. This can be useful in some cases where external load balancers are used.

Default: null
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

allow.auto.create.topics

clientmediumdynamic3.94.14.2

Allow automatic topic creation on the broker when subscribing to or assigning a topic. A topic being subscribed to will be automatically created only if the broker allows for it using `auto.create.topics.enable` broker configuration.

Default: true
Valid range: true or false
Scope: client
Related configs: auto.create.topics.enable

When you'd change it: Change this when you need to decide whether topic creation should be deliberate or implicit. The use case is usually moving from development convenience to production governance, where typos and accidental topic creation become expensive.

alter.config.policy.class.name

brokerlowstatic3.94.14.2

The alter configs policy class that should be used for validation. The class should implement the `org.apache.kafka.server.policy.AlterConfigPolicy` interface. Note: This policy runs on the controller instead of the broker.

Default: null
Valid range: A fully qualified class name
Scope: broker
Related configs: org.apache.kafka.server.policy.AlterConfigPolicy

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

alter.log.dirs.replication.quota.window.num

brokerlowstatic3.94.14.2

The number of samples to retain in memory for alter log dirs replication quotas

Default: 11
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

alter.log.dirs.replication.quota.window.size.seconds

brokerlowstatic3.94.14.2

The time span of each sample for alter log dirs replication quotas

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

authorizer.class.name

brokerlowstatic3.94.14.2

The fully qualified name of a class that implements `org.apache.kafka.server.authorizer.Authorizer` interface, which is used by the broker for authorization.

Default: ""
Valid range: non-null string
Scope: broker
Related configs: org.apache.kafka.server.authorizer.Authorizer

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

auto.commit.interval.ms

clientlowdynamic3.94.14.2

The frequency in milliseconds that the consumer offsets are auto-committed to Kafka if `enable.auto.commit` is set to `true`.

Default: 5000 (5 seconds)
Valid range: [0,...]
Scope: client
Related configs: enable.auto.commit

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

auto.create.topics.enable

brokerhighstatic3.94.14.2

Enable auto creation of topic on the server.

Default: true
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when you need to decide whether topic creation should be deliberate or implicit. The use case is usually moving from development convenience to production governance, where typos and accidental topic creation become expensive.

auto.leader.rebalance.enable

brokerhighstatic3.94.14.2

Enables auto leader balancing. A background thread checks the distribution of partition leaders at regular intervals, configurable by leader.imbalance.check.interval.seconds. If the leader is imbalanced, leader rebalance to the preferred leader for partitions is triggered.

Default: true
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

auto.offset.reset

clientmediumdynamic3.94.14.2

What to do when there is no initial offset in Kafka or if the current offset does not exist any more on the server (e.g. because that data has been deleted): earliest: automatically reset the offset to the earliest offset latest: automatically reset the offset to the latest offset by_duration:<duration>: automatically reset the offset to a configured <duration> from the current timestamp. <duration> must be specified in ISO8601 format (PnDTnHnMn.nS). Negative duration is not allowed. none: throw exception to the consumer if no previous offset is found for the consumer's group anything else: throw exception to the consumer. Note that altering partition numbers while setting this config to latest may cause message delivery loss since producers could start to send messages to newly added partitions (i.e. no initial offsets exist yet) before consumers reset their offsets.

Default: latest
Valid range: [latest, earliest, none, by_duration:PnDTnHnMn.nS]
Scope: client
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

background.threads

brokerhighdynamic3.94.14.2

The number of threads to use for various background processing tasks

Default: 10
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

batch.size

clientmediumdynamic3.94.14.2

The producer will attempt to batch records together into fewer requests whenever multiple records are being sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt will be made to batch records larger than this size. Requests sent to brokers will contain multiple batches, one for each partition with data available to be sent. A small batch size will make batching less common and may reduce throughput (a batch size of zero will disable batching entirely). A very large batch size may use memory a bit more wastefully as we will always allocate a buffer of the specified batch size in anticipation of additional records. Note: This setting gives the upper bound of the batch size to be sent. If we have fewer than this many bytes accumulated for this partition, we will 'linger' for the `linger.ms` time waiting for more records to show up. This `linger.ms` setting defaults to 5, which means the producer will wait for 5ms or until the record batch is of `batch.size` (whichever happens first) before sending the record batch. Note that broker backpressure can result in a higher effective linger time than this setting. The default changed from 0 to 5 in Apache Kafka 4.0 as the efficiency gains from larger batches typically result in similar or lower producer latency despite the increased linger.

Default: 16384
Valid range: [0,...]
Scope: client
Related configs: linger.ms

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

bootstrap.servers

clienthighdynamic3.94.14.2

A list of host/port pairs used to establish the initial connection to the Kafka cluster. Clients use this list to bootstrap and discover the full set of Kafka brokers. While the order of servers in the list does not matter, we recommend including more than one server to ensure resilience if any servers are down. This list does not need to contain the entire set of brokers, as Kafka clients automatically manage and update connections to the cluster efficiently. This list must be in the form `host1:port1,host2:port2,...`.

Default: Not specified
Valid range: A comma-separated list of values
Scope: client
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

broker.heartbeat.interval.ms

brokermediumstatic3.94.14.2

The length of time in milliseconds between broker heartbeats.

Default: 2000 (2 seconds)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

broker.id

brokerhighstatic3.94.14.2

The broker id for this server.

Default: -1
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

broker.rack

brokermediumstatic3.94.14.2

Rack of the broker. This will be used in rack aware replication assignment for fault tolerance. Examples: `RACK1`, `us-east-1d`

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

broker.session.timeout.ms

brokermediumstatic3.94.14.2

The length of time in milliseconds that a broker lease lasts if no heartbeats are made.

Default: 9000 (9 seconds)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

buffer.memory

clienthighdynamic3.94.14.2

The total bytes of memory the producer can use to buffer records waiting to be sent to the server. If records are sent faster than they can be delivered to the server the producer will block for `max.block.ms` after which it will fail with an exception. This setting should correspond roughly to the total memory the producer will use, but is not a hard bound since not all memory the producer uses is used for buffering. Some additional memory will be used for compression (if compression is enabled) as well as for maintaining in-flight requests.

Default: 33554432
Valid range: [0,...]
Scope: client
Related configs: max.block.ms

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

check.crcs

clientlowdynamic3.94.14.2

Automatically check the CRC32 of the records consumed. This ensures no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so it may be disabled in cases seeking extreme performance.

Default: true
Valid range: true or false
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

cleanup.policy

topicmediumdynamic3.94.14.2

This config designates the retention policy to use on log segments. The "delete" policy (which is the default) will discard old segments when their retention time or size limit has been reached. The "compact" policy will enable log compaction , which retains the latest value for each key. It is also possible to specify both policies in a comma-separated list (e.g. "delete,compact"). In this case, old segments will be discarded per the retention time and size configuration, while retained segments will be compacted. An empty list means infinite retention - no cleanup policies will be applied and log segments will be retained indefinitely. Note that with remote storage enabled, local retention limits (log.local.retention.ms and log.local.retention.bytes) are still applied to local segments.

Default: delete
Valid range: [compact, delete]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

client.dns.lookup

clientmediumdynamic3.94.14.2

Controls how the client uses DNS lookups. If set to `use_all_dns_ips`, connect to each returned IP address in sequence until a successful connection is established. After a disconnection, the next IP is used. Once all IPs have been used once, the client resolves the IP(s) from the hostname again (both the JVM and the OS cache DNS name lookups, however). If set to `resolve_canonical_bootstrap_servers_only`, resolve each bootstrap address into a list of canonical names. After the bootstrap phase, this behaves the same as `use_all_dns_ips`.

Default: use_all_dns_ips
Valid range: [use_all_dns_ips, resolve_canonical_bootstrap_servers_only]
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

client.id

clientmediumdynamic3.94.14.2

An id string to pass to the server when making requests. The purpose of this is to be able to track the source of requests beyond just ip/port by allowing a logical application name to be included in server-side request logging.

Default: ""
Valid range: Any valid string value
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

client.quota.callback.class

brokerlowstatic3.94.14.2

The fully qualified name of a class that implements the ClientQuotaCallback interface, which is used to determine quota limits applied to client requests. By default, the <user> and <client-id&gt quotas that are stored and applied. For any given request, the most specific quota that matches the user principal of the session and the client-id of the request is applied.

Default: null
Valid range: A fully qualified class name
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

client.rack

clientlowdynamic3.94.14.2

A rack identifier for this client. This can be any string value which indicates where this client is physically located. It corresponds with the broker config 'broker.rack'

Default: ""
Valid range: Any valid string value
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

compression.gzip.level

brokermediumdynamic3.94.14.2

The compression level to use if compression.type is set to 'gzip'.

Default: -1
Valid range: [1,...,9] or -1
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

compression.lz4.level

brokermediumdynamic3.94.14.2

The compression level to use if compression.type is set to 'lz4'.

Default: 9
Valid range: [1,...,17]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

compression.type

clienthighdynamic3.94.14.2

The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are `none`, `gzip`, `snappy`, `lz4`, or `zstd`. Compression is of full batches of data, so the efficacy of batching will also impact the compression ratio (more batching means better compression).

Default: none
Valid range: [none, gzip, snappy, lz4, zstd]
Scope: client
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

compression.zstd.level

brokermediumdynamic3.94.14.2

The compression level to use if compression.type is set to 'zstd'.

Default: 3
Valid range: [-131072,...,22]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

config.providers

brokerlowdynamic4.2

Comma-separated alias names for classes implementing the `ConfigProvider` interface. This enables loading configuration data (such as passwords, API keys, and other credentials) from external sources. For example, see Configuration Providers .

Default: ""
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

connection.failed.authentication.delay.ms

brokerlowstatic3.94.14.2

Connection close delay on failed authentication: this is the time (in milliseconds) by which connection close will be delayed on authentication failure. This must be configured to be less than connections.max.idle.ms to prevent connection timeout.

Default: 100
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

connections.max.idle.ms

brokermediumstatic3.94.14.2

Idle connections timeout: the server socket processor threads close the connections that idle more than this

Default: 600000 (10 minutes)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

connections.max.reauth.ms

brokermediumstatic3.94.14.2

When explicitly set to a positive number (the default is 0, not a positive number), a session lifetime that will not exceed the configured value will be communicated to v2.2.0 or later clients when they authenticate. The broker will disconnect any such connection that is not re-authenticated within the session lifetime and that is then subsequently used for any purpose other than re-authentication. Configuration names can optionally be prefixed with listener prefix and SASL mechanism name in lower-case. For example, listener.name.sasl_ssl.oauthbearer.connections.max.reauth.ms=3600000

Default: 0
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

controlled.shutdown.enable

brokermediumstatic3.94.14.2

Enable controlled shutdown of the server.

Default: true
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

controller.listener.names

brokerhighstatic3.94.14.2

A comma-separated list of the names of the listeners used by the controller. This is required when communicating with the controller quorum, the broker will always use the first listener in this list.

Default: Not specified
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

controller.quorum.append.linger.ms

brokermediumstatic3.94.14.2

The duration in milliseconds that the leader will wait for writes to accumulate before flushing them to disk.

Default: 25
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

controller.quorum.auto.join.enable

brokerlowstatic4.2

Controls whether a KRaft controller should automatically join the cluster metadata partition for its cluster id.

Default: false
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

controller.quorum.bootstrap.servers

brokerhighstatic3.94.14.2

List of endpoints to use for bootstrapping the cluster metadata. The endpoints are specified in comma-separated list of `{host}:{port}` entries. For example: `localhost:9092,localhost:9093,localhost:9094`.

Default: ""
Valid range: non-empty list
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

controller.quorum.election.backoff.max.ms

brokerhighstatic3.94.14.2

Maximum time in milliseconds before starting new elections. This is used in the binary exponential backoff mechanism that helps prevent gridlocked elections

Default: 1000 (1 second)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

controller.quorum.election.timeout.ms

brokerhighstatic3.94.14.2

Maximum time in milliseconds to wait without being able to fetch from the leader before triggering a new election

Default: 1000 (1 second)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

controller.quorum.fetch.timeout.ms

brokerhighstatic3.94.14.2

Maximum time without a successful fetch from the current leader before becoming a candidate and triggering an election for voters; Maximum time a leader can go without receiving valid fetch or fetchSnapshot request from a majority of the quorum before resigning.

Default: 2000 (2 seconds)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

controller.quorum.request.timeout.ms

brokermediumstatic3.94.14.2

The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted.

Default: 2000 (2 seconds)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

controller.quorum.retry.backoff.ms

brokerlowstatic3.94.14.2

The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios. This value is the initial backoff value and will increase exponentially for each failed request, up to the `retry.backoff.max.ms` value.

Default: 20
Valid range: [0,...]
Scope: broker
Related configs: retry.backoff.max.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

controller.quorum.voters

brokerhighstatic3.94.14.2

Map of id/endpoint information for the set of voters in a comma-separated list of `{id}@{host}:{port}` entries. This is the old way of defining membership for controller quorums and should NOT be set if using dynamic quorums. Instead, controller.quorum.bootstrap.servers should be set,and the voter set is determined by the --standalone or --initial-controllers flags when formatting.For example: `1@localhost:9092,2@localhost:9093,3@localhost:9094`

Default: ""
Valid range: non-empty list
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

controller.quota.window.num

brokerlowstatic3.94.14.2

The number of samples to retain in memory for controller mutation quotas

Default: 11
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

controller.quota.window.size.seconds

brokerlowstatic3.94.14.2

The time span of each sample for controller mutations quotas

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

controller.socket.timeout.ms

brokermediumstatic3.94.14.2

The socket timeout for controller-to-broker channels.

Default: 30000 (30 seconds)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

create.topic.policy.class.name

brokerlowstatic3.94.14.2

The create topic policy class that should be used for validation. The class should implement the `org.apache.kafka.server.policy.CreateTopicPolicy` interface. Note: This policy runs on the controller instead of the broker.

Default: null
Valid range: A fully qualified class name
Scope: broker
Related configs: org.apache.kafka.server.policy.CreateTopicPolicy

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

default.api.timeout.ms

clientmediumdynamic3.94.14.2

Specifies the timeout (in milliseconds) for client APIs. This configuration is used as the default timeout for all client operations that do not specify a `timeout` parameter.

Default: 60000 (1 minute)
Valid range: [0,...]
Scope: client
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

default.replication.factor

brokermediumstatic3.94.14.2

The replication factor for automatically created topics, and for topics created with -1 as the replication factor

Default: 1
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

delegation.token.expiry.check.interval.ms

brokerlowstatic3.94.14.2

Scan interval to remove expired delegation tokens.

Default: 3600000 (1 hour)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

delegation.token.expiry.time.ms

brokermediumstatic3.94.14.2

The token validity time in milliseconds before the token needs to be renewed. Default value 1 day.

Default: 86400000 (1 day)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

delegation.token.max.lifetime.ms

brokermediumstatic3.94.14.2

The token has a maximum lifetime beyond which it cannot be renewed anymore. Default value 7 days.

Default: 604800000 (7 days)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

delegation.token.secret.key

brokermediumstatic3.94.14.2

Secret key to generate and verify delegation tokens. The same key must be configured across all the brokers. If using Kafka with KRaft, the key must also be set across all controllers. If the key is not set or set to empty string, brokers will disable the delegation token support.

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

delete.records.purgatory.purge.interval.requests

brokermediumstatic3.94.14.2

The purge interval (in number of requests) of the delete records request purgatory

Default: 1
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

delete.retention.ms

topicmediumdynamic3.94.14.2

The amount of time to retain delete tombstone markers for log compacted topics. This setting also gives a bound on the time in which a consumer must complete a read if they begin from offset 0 to ensure that they get a valid snapshot of the final stage (otherwise delete tombstones may be collected before they complete their scan).

Default: 86400000 (1 day)
Valid range: [0,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

delete.topic.enable

brokerhighstatic3.94.14.2

When set to true, topics can be deleted by the admin client. When set to false, deletion requests will be explicitly rejected by the broker.

Default: true
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

delivery.timeout.ms

clientmediumdynamic3.94.14.2

An upper bound on the time to report success or failure after a call to `send()` returns. This limits the total time that a record will be delayed prior to sending, the time to await acknowledgement from the broker (if expected), and the time allowed for retriable send failures. The producer may report failure to send a record earlier than this config if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch which reached an earlier delivery expiration deadline. The value of this config should be greater than or equal to the sum of `request.timeout.ms` and `linger.ms`.

Default: 120000 (2 minutes)
Valid range: [0,...]
Scope: client
Related configs: request.timeout.ms, linger.ms

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

early.start.listeners

brokerhighstatic3.94.14.2

A comma-separated list of listener names which may be started before the authorizer has finished initialization. This is useful when the authorizer is dependent on the cluster itself for bootstrapping, as is the case for the StandardAuthorizer (which stores ACLs in the metadata log.) By default, all listeners included in controller.listener.names will also be early start listeners. A listener should not appear in this list if it accepts external traffic.

Default: null
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

enable.auto.commit

clientmediumdynamic3.94.14.2

If true the consumer's offset will be periodically committed in the background.

Default: true
Valid range: true or false
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

enable.idempotence

clientlowdynamic3.94.14.2

When set to 'true', the producer will ensure that exactly one copy of each message is written in the stream. If 'false', producer retries due to broker failures, etc., may write duplicates of the retried message in the stream. Note that enabling idempotence requires `max.in.flight.requests.per.connection` to be less than or equal to 5 (with message ordering preserved for any allowable value), `retries` to be greater than 0, and `acks` must be 'all'. Idempotence is enabled by default if no conflicting configurations are set. If conflicting configurations are set and idempotence is not explicitly enabled, idempotence is disabled. If idempotence is explicitly enabled and conflicting configurations are set, a `ConfigException` is thrown.

Default: true
Valid range: true or false
Scope: client
Related configs: max.in.flight.requests.per.connection

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

enable.metrics.push

clientlowdynamic3.94.14.2

Whether to enable pushing of client metrics to the cluster, if the cluster has a client metrics subscription which matches this client.

Default: true
Valid range: true or false
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

exclude.internal.topics

clientmediumdynamic3.94.14.2

Whether internal topics matching a subscribed pattern should be excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.

Default: true
Valid range: true or false
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

fetch.max.bytes

clientmediumdynamic3.94.14.2

The maximum amount of data the server should return for a fetch request. Records are fetched in batches by the consumer, and if the first record batch in the first non-empty partition of the fetch is larger than this value, the record batch will still be returned to ensure that the consumer can make progress. As such, this is not a absolute maximum. The maximum record batch size accepted by the broker is defined via `message.max.bytes` (broker config) or `max.message.bytes` (topic config). A fetch request consists of many partitions, and there is another setting that controls how much data is returned for each partition in a fetch request - see `max.partition.fetch.bytes`. Note that the consumer performs multiple fetches in parallel.

Default: 52428800 (50 mebibytes)
Valid range: [0,...]
Scope: client
Related configs: message.max.bytes, max.message.bytes, max.partition.fetch.bytes

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

fetch.max.wait.ms

clientlowdynamic3.94.14.2

The maximum amount of time the server will block before answering the fetch request there isn't sufficient data to immediately satisfy the requirement given by fetch.min.bytes. This config is used only for local log fetch. To tune the remote fetch maximum wait time, please refer to 'remote.fetch.max.wait.ms' broker config

Default: 500
Valid range: [0,...]
Scope: client
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

fetch.min.bytes

clienthighdynamic3.94.14.2

The minimum amount of data the server should return for a fetch request. If insufficient data is available the request will wait for that much data to accumulate before answering the request. The default setting of 1 byte means that fetch requests are answered as soon as that many byte(s) of data is available or the fetch request times out waiting for data to arrive. Setting this to a larger value will cause the server to wait for larger amounts of data to accumulate which can improve server throughput a bit at the cost of some additional latency. Even if the total data available in the broker exceeds fetch.min.bytes, the actual returned size may still be less than this value due to per-partition limits max.partition.fetch.bytes and max returned limits fetch.max.bytes.

Default: 1
Valid range: [0,...]
Scope: client
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

fetch.purgatory.purge.interval.requests

brokermediumstatic3.94.14.2

The purge interval (in number of requests) of the fetch request purgatory

Default: 1000
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

file.delete.delay.ms

topicmediumdynamic3.94.14.2

The time to wait before deleting a file from the filesystem

Default: 60000 (1 minute)
Valid range: [0,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

flush.messages

topicmediumdynamic3.94.14.2

This setting allows specifying an interval at which we will force an fsync of data written to the log. For example if this was set to 1 we would fsync after every message; if it were 5 we would fsync after every five messages. In general we recommend you not set this and use replication for durability and allow the operating system's background flush capabilities as it is more efficient. This setting can be overridden on a per-topic basis (see the per-topic configuration section ).

Default: 9223372036854775807
Valid range: [1,...]
Scope: topic
Related configs

When you'd change it: Change this when the topic-level behavior needs to match the workload more closely. The use case is usually tuning retention, cleanup, message handling, or replication for a specific topic rather than the whole cluster.

flush.ms

topicmediumdynamic3.94.14.2

This setting allows specifying a time interval at which we will force an fsync of data written to the log. For example if this was set to 1000 we would fsync after 1000 ms had passed. Note that this setting depends on the broker-level configuration `log.flush.scheduler.interval.ms`, which controls how frequently the flush check occurs. In general we recommend you not set this and use replication for durability and allow the operating system's background flush capabilities as it is more efficient.

Default: 9223372036854775807
Valid range: [0,...]
Scope: topic
Related configs: log.flush.scheduler.interval.ms

When you'd change it: Change this when the topic-level behavior needs to match the workload more closely. The use case is usually tuning retention, cleanup, message handling, or replication for a specific topic rather than the whole cluster.

follower.replication.throttled.replicas

topicmediumdynamic3.94.14.2

A list of replicas for which log replication should be throttled on the follower side. The list should describe a set of replicas in the form [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:... or alternatively the wildcard '*' can be used to throttle all replicas for this topic.

Default: ""
Valid range: [partitionId]:[brokerId],[partitionId]:[brokerId],...
Scope: topic
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

group.consumer.assignors

brokermediumstatic3.94.14.2

The server side assignors as a list of either names for builtin assignors or full class names for customer assignors. The first one in the list is considered as the default assignor to be used in the case where the consumer does not specify an assignor. The supported builtin assignors are: uniform, range.

Default: uniform,range
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.consumer.heartbeat.interval.ms

brokermediumstatic3.94.14.2

The heartbeat interval given to the members of a consumer group.

Default: 5000 (5 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.consumer.max.heartbeat.interval.ms

brokermediumstatic3.94.14.2

The maximum heartbeat interval for registered consumers.

Default: 15000 (15 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.consumer.max.session.timeout.ms

brokermediumstatic3.94.14.2

The maximum allowed session timeout for registered consumers.

Default: 60000 (1 minute)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.consumer.max.size

brokermediumstatic3.94.14.2

The maximum number of consumers that a single consumer group can accommodate. This value will only impact groups under the CONSUMER group protocol. To configure the max group size when using the CLASSIC group protocol use group.max.size instead.

Default: 2147483647
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

group.consumer.migration.policy

brokermediumstatic4.14.2

The config that enables converting the non-empty classic group using the consumer embedded protocol to the non-empty consumer group using the consumer group protocol and vice versa; conversions of empty groups in both directions are always enabled regardless of this policy. bidirectional: both upgrade from classic group to consumer group and downgrade from consumer group to classic group are enabled, upgrade: only upgrade from classic group to consumer group is enabled, downgrade: only downgrade from consumer group to classic group is enabled, disabled: neither upgrade nor downgrade is enabled.

Default: bidirectional
Valid range: (case insensitive) [DISABLED, DOWNGRADE, UPGRADE, BIDIRECTIONAL]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.consumer.min.heartbeat.interval.ms

brokermediumstatic3.94.14.2

The minimum heartbeat interval for registered consumers.

Default: 5000 (5 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.consumer.min.session.timeout.ms

brokermediumstatic3.94.14.2

The minimum allowed session timeout for registered consumers.

Default: 45000 (45 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.consumer.session.timeout.ms

brokermediumstatic3.94.14.2

The timeout to detect client failures when using the consumer group protocol.

Default: 45000 (45 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.coordinator.append.linger.ms

brokermediumstatic3.94.14.2

The duration in milliseconds that the coordinator will wait for writes to accumulate before flushing them to disk. Increasing this value improves write efficiency and batch size, but also increases the response latency for requests, as the coordinator must wait for batches to be flushed to disk before completing request processing. Transactional writes are not accumulated. Set to -1 for an adaptive linger time that minimizes latency based on the workload.

Default: -1
Valid range: [-1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

group.coordinator.rebalance.protocols

brokermediumstatic3.94.14.2

The list of enabled rebalance protocols.

Default: classic,consumer,streams
Valid range: [consumer, classic, share, streams]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.coordinator.threads

brokerhighstatic3.94.14.2

The number of threads used by the group coordinator.

Default: 4
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

group.id

clienthighdynamic3.94.14.2

A unique string that identifies the consumer group this consumer belongs to. This property is required if the consumer uses either the group management functionality by using `subscribe(topic)` or the Kafka-based offset management strategy.

Default: null
Valid range: Any valid string value
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

group.initial.rebalance.delay.ms

brokermediumstatic3.94.14.2

The amount of time the group coordinator will wait for more consumers to join a new group before performing the first rebalance. A longer delay means potentially fewer rebalances, but increases the time until processing begins.

Default: 3000 (3 seconds)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.instance.id

clientmediumdynamic3.94.14.2

A unique identifier of the consumer instance provided by the end user. Only non-empty strings are permitted. If set, the consumer is treated as a static member, which means that only one instance with this ID is allowed in the consumer group at any time. This can be used in combination with a larger session timeout to avoid group rebalances caused by transient unavailability (e.g. process restarts). If not set, the consumer will join the group as a dynamic member, which is the traditional behavior.

Default: null
Valid range: non-empty string
Scope: client
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.max.session.timeout.ms

brokermediumstatic3.94.14.2

The maximum allowed session timeout for registered consumers. Longer timeouts give consumers more time to process messages in between heartbeats at the cost of a longer time to detect failures.

Default: 1800000 (30 minutes)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.max.size

brokermediumstatic3.94.14.2

The maximum number of consumers that a single consumer group can accommodate.

Default: 2147483647
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

group.min.session.timeout.ms

brokermediumstatic3.94.14.2

The minimum allowed session timeout for registered consumers. Shorter timeouts result in quicker failure detection at the cost of more frequent consumer heartbeating, which can overwhelm broker resources.

Default: 6000 (6 seconds)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.protocol

clienthighdynamic3.94.14.2

The group protocol that the consumer uses. The supported values are `classic` or `consumer`. The default value is `classic`.

Default: classic
Valid range: (case insensitive) [CONSUMER, CLASSIC]
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

group.remote.assignor

clientmediumdynamic3.94.14.2

The name of the server-side assignor to use. If not specified, the group coordinator will pick the first assignor defined in the broker config group.consumer.assignors.This configuration is applied only if `group.protocol` is set to "consumer".

Default: null
Valid range: Any valid string value
Scope: client
Related configs: group.protocol

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

group.share.assignors

brokermediumstatic4.14.2

The server-side assignors as a list of either names for built-in assignors or full class names for custom assignors. The list must contain only a single entry which is used by all groups. The supported built-in assignors are: simple.

Default: simple
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.share.delivery.count.limit

brokermediumstatic3.94.14.2

The maximum number of delivery attempts for a record delivered to a share group.

Default: 5
Valid range: [2,...,10]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.share.heartbeat.interval.ms

brokermediumstatic3.94.14.2

The heartbeat interval given to the members of a share group.

Default: 5000 (5 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.share.max.heartbeat.interval.ms

brokermediumstatic3.94.14.2

The maximum heartbeat interval for share group members.

Default: 15000 (15 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.share.max.record.lock.duration.ms

brokermediumstatic3.94.14.2

The record acquisition lock maximum duration in milliseconds for share groups.

Default: 60000 (1 minute)
Valid range: [30000,...,3600000]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.share.max.session.timeout.ms

brokermediumstatic3.94.14.2

The maximum allowed session timeout for share group members.

Default: 60000 (1 minute)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.share.max.share.sessions

brokermediumstatic4.14.2

The maximum number of share sessions per broker.

Default: 2000
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.share.max.size

brokermediumstatic3.94.14.2

The maximum number of members that a single share group can accommodate.

Default: 200
Valid range: [1,...,1000]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

group.share.min.heartbeat.interval.ms

brokermediumstatic3.94.14.2

The minimum heartbeat interval for share group members.

Default: 5000 (5 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.share.min.record.lock.duration.ms

brokermediumstatic3.94.14.2

The record acquisition lock minimum duration in milliseconds for share groups.

Default: 15000 (15 seconds)
Valid range: [1000,...,30000]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.share.min.session.timeout.ms

brokermediumstatic3.94.14.2

The minimum allowed session timeout for share group members.

Default: 45000 (45 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.share.partition.max.record.locks

brokermediumstatic3.94.14.2

Share-group record lock limit per share-partition.

Default: 2000
Valid range: [100,...,10000]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

group.share.record.lock.duration.ms

brokermediumstatic3.94.14.2

The record acquisition lock duration in milliseconds for share groups.

Default: 30000 (30 seconds)
Valid range: [1000,...,3600000]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.share.session.timeout.ms

brokermediumstatic3.94.14.2

The timeout to detect client failures when using the share group protocol.

Default: 45000 (45 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.streams.heartbeat.interval.ms

brokermediumstatic4.14.2

The heartbeat interval given to the members.

Default: 5000 (5 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.streams.initial.rebalance.delay.ms

brokermediumstatic4.2

The amount of time the group coordinator will wait for more streams clients to join a new group before performing the first rebalance. A longer delay means potentially fewer rebalances.

Default: 3000 (3 seconds)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.streams.max.heartbeat.interval.ms

brokermediumstatic4.14.2

The maximum allowed value for the group-level configuration of streams.heartbeat.interval.ms

Default: 15000 (15 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.streams.max.session.timeout.ms

brokermediumstatic4.14.2

The maximum allowed value for the group-level configuration of streams.session.timeout.ms

Default: 60000 (1 minute)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.streams.max.size

brokermediumstatic4.14.2

The maximum number of streams clients that a single streams group can accommodate.

Default: 2147483647
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

group.streams.max.standby.replicas

brokermediumstatic4.14.2

The maximum allowed value for the group-level configuration of streams.num.standby.replicas

Default: 2
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.streams.min.heartbeat.interval.ms

brokermediumstatic4.14.2

The minimum allowed value for the group-level configuration of streams.heartbeat.interval.ms

Default: 5000 (5 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.streams.min.session.timeout.ms

brokermediumstatic4.14.2

The minimum allowed value for the group-level configuration of streams.session.timeout.ms

Default: 45000 (45 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

group.streams.num.standby.replicas

brokermediumstatic4.14.2

The number of standby replicas for each task.

Default: 0
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

group.streams.session.timeout.ms

brokermediumstatic4.14.2

The timeout to detect client failures when using the streams group protocol.

Default: 45000 (45 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

heartbeat.interval.ms

clienthighdynamic3.94.14.2

The expected time between heartbeats to the consumer coordinator when using Kafka's group management facilities. Heartbeats are used to ensure that the consumer's session stays active and to facilitate rebalancing when new consumers join or leave the group. This config is only supported if `group.protocol` is set to "classic". In that case, the value must be set lower than `session.timeout.ms`, but typically should be set no higher than 1/3 of that value. It can be adjusted even lower to control the expected time for normal rebalances.If `group.protocol` is set to "consumer", this config is not supported, as the heartbeat interval is controlled by the broker with `group.consumer.heartbeat.interval.ms`.

Default: 3000 (3 seconds)
Valid range: Any valid integer unless constrained elsewhere
Scope: client
Related configs: group.protocol, session.timeout.ms, group.consumer.heartbeat.interval.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

index.interval.bytes

topicmediumdynamic3.94.14.2

This setting controls how frequently Kafka adds entries to its offset index and, conditionally, to its time index. The default setting ensures that we index a message roughly every 4096 bytes. More frequent indexing allows reads to jump closer to the exact position in the log but results in larger index files. You probably don't need to change this. Note: the time index will be inserted only when the timestamp is greater than the last indexed timestamp.

Default: 4096 (4 kibibytes)
Valid range: [0,...]
Scope: topic
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

initial.broker.registration.timeout.ms

brokermediumstatic3.94.14.2

When initially registering with the controller quorum, the number of milliseconds to wait before declaring failure and exiting the broker process.

Default: 60000 (1 minute)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

inter.broker.listener.name

brokermediumstatic3.94.14.2

Name of listener used for communication between brokers. If this is unset, the listener name is defined by security.inter.broker.protocol. It is an error to set this and security.inter.broker.protocol properties at the same time.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

interceptor.classes

clientlowdynamic3.94.14.2

A list of classes to use as interceptors. Implementing the `org.apache.kafka.clients.producer.ProducerInterceptor` interface allows you to intercept (and possibly mutate) the records received by the producer before they are published to the Kafka cluster. By default, there are no interceptors.

Default: ""
Valid range: A comma-separated list of values
Scope: client
Related configs: org.apache.kafka.clients.producer.ProducerInterceptor

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

isolation.level

clientmediumdynamic3.94.14.2

Controls how to read messages written transactionally. If set to `read_committed`, consumer.poll() will only return transactional messages which have been committed. If set to `read_uncommitted` (the default), consumer.poll() will return all messages, even transactional messages which have been aborted. Non-transactional messages will be returned unconditionally in either mode. Messages will always be returned in offset order. Hence, in `read_committed` mode, consumer.poll() will only return messages up to the last stable offset (LSO), which is the one less than the offset of the first open transaction. In particular any messages appearing after messages belonging to ongoing transactions will be withheld until the relevant transaction has been completed. As a result, `read_committed` consumers will not be able to read up to the high watermark when there are in flight transactions. Further, when in `read_committed` the seekToEnd method will return the LSO

Default: read_uncommitted
Valid range: [read_committed, read_uncommitted]
Scope: client
Related configs

When you'd change it: Change this when the use case requires duplicate protection or transactional guarantees across retries and restarts. These settings matter when correctness is more important than keeping the client configuration minimal.

kafka.metrics.polling.interval.secs

brokerlowstatic3.94.14.2

The metrics polling interval (in seconds) which can be used in kafka.metrics.reporters implementations.

Default: 10
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

kafka.metrics.reporters

brokerlowstatic3.94.14.2

A list of classes to use as Yammer metrics custom reporters. The reporters should implement `kafka.metrics.KafkaMetricsReporter` trait. If a client wants to expose JMX operations on a custom reporter, the custom reporter needs to additionally implement an MBean trait that extends `kafka.metrics.KafkaMetricsReporterMBean` trait so that the registered MBean is compliant with the standard MBean convention.

Default: ""
Valid range: A comma-separated list of values
Scope: broker
Related configs: kafka.metrics.KafkaMetricsReporter, kafka.metrics.KafkaMetricsReporterMBean

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

key.deserializer

clienthighdynamic3.94.14.2

Deserializer class for key that implements the `org.apache.kafka.common.serialization.Deserializer` interface.

Default: Not specified
Valid range: A fully qualified class name
Scope: client
Related configs: org.apache.kafka.common.serialization.Deserializer

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

key.serializer

clienthighdynamic3.94.14.2

Serializer class for key that implements the `org.apache.kafka.common.serialization.Serializer` interface.

Default: Not specified
Valid range: A fully qualified class name
Scope: client
Related configs: org.apache.kafka.common.serialization.Serializer

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

leader.imbalance.check.interval.seconds

brokerhighstatic3.94.14.2

The frequency with which the partition rebalance check is triggered by the controller

Default: 300
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

leader.replication.throttled.replicas

topicmediumdynamic3.94.14.2

A list of replicas for which log replication should be throttled on the leader side. The list should describe a set of replicas in the form [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:... or alternatively the wildcard '*' can be used to throttle all replicas for this topic.

Default: ""
Valid range: [partitionId]:[brokerId],[partitionId]:[brokerId],...
Scope: topic
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

linger.ms

clientmediumdynamic3.94.14.2

The producer groups together any records that arrive in between request transmissions into a single batched request. Normally this occurs only under load when records arrive faster than they can be sent out. However in some circumstances the client may want to reduce the number of requests even under moderate load. This setting accomplishes this by adding a small amount of artificial delay—that is, rather than immediately sending out a record, the producer will wait for up to the given delay to allow other records to be sent so that the sends can be batched together. This can be thought of as analogous to Nagle's algorithm in TCP. This setting gives the upper bound on the delay for batching: once we get `batch.size` worth of records for a partition it will be sent immediately regardless of this setting, however if we have fewer than this many bytes accumulated for this partition we will 'linger' for the specified time waiting for more records to show up. This setting defaults to 5 (i.e. 5ms delay). Increasing `linger.ms=50`, for example, would have the effect of reducing the number of requests sent but would add up to 50ms of latency to records sent in the absence of load.The default changed from 0 to 5 in Apache Kafka 4.0 as the efficiency gains from larger batches typically result in similar or lower producer latency despite the increased linger.

Default: 5
Valid range: [0,...]
Scope: client
Related configs: batch.size

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

listener.security.protocol.map

brokerlowdynamic3.94.14.2

Map between listener names and security protocols. This must be defined for the same security protocol to be usable in more than one port or IP. For example, internal and external traffic can be separated even if SSL is required for both. Concretely, the user could define listeners with names INTERNAL and EXTERNAL and this property as: `INTERNAL:SSL,EXTERNAL:SSL`. As shown, key and value are separated by a colon and map entries are separated by commas. Each listener name should only appear once in the map. Different security (SSL and SASL) settings can be configured for each listener by adding a normalised prefix (the listener name is lowercased) to the config name. For example, to set a different keystore for the INTERNAL listener, a config with name `listener.name.internal.ssl.keystore.location` would be set. If the config for the listener name is not set, the config will fallback to the generic config (i.e. `ssl.keystore.location`). Note that in KRaft a default mapping from the listener names defined by `controller.listener.names` to PLAINTEXT is assumed if no explicit mapping is provided and no other security protocol is in use.

Default: SASL_SSL:SASL_SSL,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT
Valid range: Any valid string value
Scope: broker
Related configs: listener.name.internal.ssl.keystore.location, ssl.keystore.location, controller.listener.names

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

listeners

brokerhighdynamic3.94.14.2

Listener List - Comma-separated list of URIs we will listen on and the listener names. If the listener name is not a security protocol, `listener.security.protocol.map` must also be set. Listener names and port numbers must be unique unless one listener is an IPv4 address and the other listener is an IPv6 address (for the same port). Specify hostname as 0.0.0.0 to bind to all interfaces. Leave hostname empty to bind to default interface. Examples of legal listener lists: `PLAINTEXT://myhost:9092,SSL://:9091` `CLIENT://0.0.0.0:9092,REPLICATION://localhost:9093` `PLAINTEXT://127.0.0.1:9092,SSL://[::1]:9092`

Default: PLAINTEXT://:9092
Valid range: A comma-separated list of values
Scope: broker
Related configs: listener.security.protocol.map

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

local.retention.bytes

topicmediumdynamic3.94.14.2

The maximum size of local log segments that can grow for a partition before it deletes the old segments. Default value is -2, it represents `retention.bytes` value to be used. The effective value should always be less than or equal to `retention.bytes` value.

Default: -2
Valid range: [-2,...]
Scope: topic
Related configs: retention.bytes

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

local.retention.ms

topicmediumdynamic3.94.14.2

The number of milliseconds to keep the local log segment before it gets deleted. Default value is -2, it represents `retention.ms` value is to be used. The effective value should always be less than or equal to `retention.ms` value.

Default: -2
Valid range: [-2,...]
Scope: topic
Related configs: retention.ms

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.cleaner.backoff.ms

brokermediumdynamic3.94.14.2

The amount of time to sleep when there are no logs to clean

Default: 15000 (15 seconds)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

log.cleaner.dedupe.buffer.size

brokermediumdynamic3.94.14.2

The total memory used for log deduplication across all cleaner threads

Default: 134217728
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

log.cleaner.delete.retention.ms

brokermediumdynamic3.94.14.2

The amount of time to retain tombstone message markers for log compacted topics. This setting also gives a bound on the time in which a consumer must complete a read if they begin from offset 0 to ensure that they get a valid snapshot of the final stage (otherwise tombstones messages may be collected before a consumer completes their scan).

Default: 86400000 (1 day)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.cleaner.enable

brokermediumstatic3.94.14.2

This configuration has been deprecated and will be removed in Kafka 5.0. Users should not set it to false to prepare for its future removal. Enable the log cleaner process to run on the server. Should be enabled if using any topics with a cleanup.policy=compact including the internal offsets topic. If disabled those topics will not be compacted and continually grow in size.

Default: true
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.cleaner.io.buffer.load.factor

brokermediumdynamic3.94.14.2

Log cleaner dedupe buffer load factor. The percentage full the dedupe buffer can become. A higher value will allow more log to be cleaned at once but will lead to more hash collisions

Default: 0.9
Valid range: Any valid decimal number unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

log.cleaner.io.buffer.size

brokermediumdynamic3.94.14.2

The total memory used for log cleaner I/O buffers across all cleaner threads

Default: 524288
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

log.cleaner.io.max.bytes.per.second

brokermediumdynamic3.94.14.2

The log cleaner will be throttled so that the sum of its read and write i/o will be less than this value on average

Default: 1.7976931348623157E308
Valid range: Any valid decimal number unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

log.cleaner.max.compaction.lag.ms

brokermediumdynamic3.94.14.2

The maximum time a message will remain ineligible for compaction in the log. Only applicable for logs that are being compacted.

Default: 9223372036854775807
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.cleaner.min.cleanable.ratio

brokermediumdynamic3.94.14.2

The minimum ratio of dirty log to total log for a log to eligible for cleaning. If the log.cleaner.max.compaction.lag.ms or the log.cleaner.min.compaction.lag.ms configurations are also specified, then the log compactor considers the log eligible for compaction as soon as either: (i) the dirty ratio threshold has been met and the log has had dirty (uncompacted) records for at least the log.cleaner.min.compaction.lag.ms duration, or (ii) if the log has had dirty (uncompacted) records for at most the log.cleaner.max.compaction.lag.ms period.

Default: 0.5
Valid range: [0,...,1]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.cleaner.min.compaction.lag.ms

brokermediumdynamic3.94.14.2

The minimum time a message will remain uncompacted in the log. Only applicable for logs that are being compacted.

Default: 0
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.cleaner.threads

brokermediumdynamic3.94.14.2

The number of background threads to use for log cleaning

Default: 1
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

log.cleanup.policy

brokermediumdynamic3.94.14.2

This config designates the retention policy to use on log segments. The "delete" policy (which is the default) will discard old segments when their retention time or size limit has been reached. The "compact" policy will enable log compaction , which retains the latest value for each key. It is also possible to specify both policies in a comma-separated list (e.g. "delete,compact"). In this case, old segments will be discarded per the retention time and size configuration, while retained segments will be compacted. An empty list means infinite retention - no cleanup policies will be applied and log segments will be retained indefinitely. Note that with remote storage enabled, local retention limits (log.local.retention.ms and log.local.retention.bytes) are still applied to local segments.

Default: delete
Valid range: [compact, delete]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.dir

brokerhighstatic3.94.14.2

A comma-separated list of the directories where the log data is stored. (supplemental to log.dirs property)

Default: /tmp/kafka-logs
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.dir.failure.timeout.ms

brokerlowstatic3.94.14.2

If the broker is unable to successfully communicate to the controller that some log directory has failed for longer than this time, the broker will fail and shut down.

Default: 30000 (30 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

log.dirs

brokerhighstatic3.94.14.2

A comma-separated list of the directories where the log data is stored. If not set, the value in log.dir is used.

Default: null
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.flush.interval.messages

brokerhighdynamic3.94.14.2

The number of messages accumulated on a log partition before messages are flushed to disk.

Default: 9223372036854775807
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

log.flush.interval.ms

brokerhighdynamic3.94.14.2

The maximum time in ms that a message in any topic is kept in memory before flushed to disk. If not set, the value in log.flush.scheduler.interval.ms is used

Default: null
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.flush.offset.checkpoint.interval.ms

brokerhighstatic3.94.14.2

The frequency with which we update the persistent record of the last flush which acts as the log recovery point.

Default: 60000 (1 minute)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.flush.scheduler.interval.ms

brokerhighstatic3.94.14.2

The frequency in ms that the log flusher checks whether any log needs to be flushed to disk

Default: 9223372036854775807
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.flush.start.offset.checkpoint.interval.ms

brokerhighstatic3.94.14.2

The frequency with which we update the persistent record of log start offset

Default: 60000 (1 minute)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.index.interval.bytes

brokermediumdynamic3.94.14.2

The interval with which we add an entry to the offset index.

Default: 4096 (4 kibibytes)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

log.index.size.max.bytes

brokermediumdynamic3.94.14.2

The maximum size in bytes of the offset index

Default: 10485760 (10 mebibytes)
Valid range: [4,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

log.local.retention.bytes

brokermediumdynamic3.94.14.2

The maximum size of local log segments that can grow for a partition before it gets eligible for deletion. Default value is -2, it represents `log.retention.bytes` value to be used. The effective value should always be less than or equal to `log.retention.bytes` value.

Default: -2
Valid range: [-2,...]
Scope: broker
Related configs: log.retention.bytes

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.local.retention.ms

brokermediumdynamic3.94.14.2

The number of milliseconds to keep the local log segments before it gets eligible for deletion. Default value is -2, it represents `log.retention.ms` value is to be used. The effective value should always be less than or equal to `log.retention.ms` value.

Default: -2
Valid range: [-2,...]
Scope: broker
Related configs: log.retention.ms

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.message.timestamp.after.max.ms

brokermediumdynamic3.94.14.2

This configuration sets the allowable timestamp difference between the message timestamp and the broker's timestamp. The message timestamp can be later than or equal to the broker's timestamp, with the maximum allowable difference determined by the value set in this configuration. If log.message.timestamp.type=CreateTime, the message will be rejected if the difference in timestamps exceeds this specified threshold. This configuration is ignored if log.message.timestamp.type=LogAppendTime.

Default: 3600000 (1 hour)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.message.timestamp.before.max.ms

brokermediumdynamic3.94.14.2

This configuration sets the allowable timestamp difference between the broker's timestamp and the message timestamp. The message timestamp can be earlier than or equal to the broker's timestamp, with the maximum allowable difference determined by the value set in this configuration. If log.message.timestamp.type=CreateTime, the message will be rejected if the difference in timestamps exceeds this specified threshold. This configuration is ignored if log.message.timestamp.type=LogAppendTime.

Default: 9223372036854775807
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.message.timestamp.type

brokermediumdynamic3.94.14.2

Define whether the timestamp in the message is message create time or log append time. The value should be either `CreateTime` or `LogAppendTime`.

Default: CreateTime
Valid range: [CreateTime, LogAppendTime]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

log.preallocate

brokermediumdynamic3.94.14.2

Should pre allocate file when create new segment? If you are using Kafka on Windows, you probably need to set it to true.

Default: false
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.retention.bytes

brokerhighdynamic3.94.14.2

The maximum size of the log before deleting it

Default: -1
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.retention.check.interval.ms

brokermediumstatic3.94.14.2

The frequency in milliseconds that the log cleaner checks whether any log is eligible for deletion

Default: 300000 (5 minutes)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.retention.hours

brokerhighstatic3.94.14.2

The number of hours to keep a log file before deleting it (in hours), tertiary to log.retention.ms property

Default: 168
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.retention.minutes

brokerhighstatic3.94.14.2

The number of minutes to keep a log file before deleting it (in minutes), secondary to log.retention.ms property. If not set, the value in log.retention.hours is used

Default: null
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.retention.ms

brokerhighdynamic3.94.14.2

The number of milliseconds to keep a log file before deleting it (in milliseconds), If not set, the value in log.retention.minutes is used. If set to -1, no time limit is applied.

Default: null
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.roll.hours

brokerhighstatic3.94.14.2

The maximum time before a new log segment is rolled out (in hours), secondary to log.roll.ms property

Default: 168
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.roll.jitter.hours

brokerhighstatic3.94.14.2

The maximum jitter to subtract from logRollTimeMillis (in hours), secondary to log.roll.jitter.ms property

Default: 0
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.roll.jitter.ms

brokerhighdynamic3.94.14.2

The maximum jitter to subtract from logRollTimeMillis (in milliseconds). If not set, the value in log.roll.jitter.hours is used

Default: null
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.roll.ms

brokerhighdynamic3.94.14.2

The maximum time before a new log segment is rolled out (in milliseconds). If not set, the value in log.roll.hours is used

Default: null
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.segment.bytes

brokerhighdynamic3.94.14.2

The maximum size of a single log file

Default: 1073741824 (1 gibibyte)
Valid range: [1048576,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

log.segment.delete.delay.ms

brokerhighdynamic3.94.14.2

The amount of time to wait before deleting a file from the filesystem. If the value is 0 and there is no file to delete, the system will wait 1 millisecond. Low value will cause busy waiting

Default: 60000 (1 minute)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

max.block.ms

clientmediumdynamic3.94.14.2

The configuration controls how long the `KafkaProducer`'s `send()`, `partitionsFor()`, `initTransactions()`, `sendOffsetsToTransaction()`, `commitTransaction()` and `abortTransaction()` methods will block. For `send()` this timeout bounds the total time waiting for both metadata fetch and buffer allocation (blocking in the user-supplied serializers or partitioner is not counted against this timeout). For `partitionsFor()` this timeout bounds the time spent waiting for metadata if it is unavailable. The transaction-related methods always block, but may timeout if the transaction coordinator could not be discovered or did not respond within the timeout.

Default: 60000 (1 minute)
Valid range: [0,...]
Scope: client
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

max.compaction.lag.ms

topicmediumdynamic3.94.14.2

The maximum time a message will remain ineligible for compaction in the log. Only applicable for logs that are being compacted.

Default: 9223372036854775807
Valid range: [1,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

max.connection.creation.rate

brokermediumdynamic3.94.14.2

The maximum connection creation rate we allow in the broker at any time. Listener-level limits may also be configured by prefixing the config name with the listener prefix, for example, `listener.name.internal.max.connection.creation.rate`.Broker-wide connection rate limit should be configured based on broker capacity while listener limits should be configured based on application requirements. New connections will be throttled if either the listener or the broker limit is reached, with the exception of inter-broker listener. Connections on the inter-broker listener will be throttled only when the listener-level rate limit is reached.

Default: 2147483647
Valid range: [0,...]
Scope: broker
Related configs: listener.name.internal.max.connection.creation.rate

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

max.connections

brokermediumdynamic3.94.14.2

The maximum number of connections we allow in the broker at any time. This limit is applied in addition to any per-ip limits configured using max.connections.per.ip. Listener-level limits may also be configured by prefixing the config name with the listener prefix, for example, `listener.name.internal.max.connections.per.ip`. Broker-wide limit should be configured based on broker capacity while listener limits should be configured based on application requirements. New connections are blocked if either the listener or broker limit is reached. Connections on the inter-broker listener are permitted even if broker-wide limit is reached. The least recently used connection on another listener will be closed in this case.

Default: 2147483647
Valid range: [0,...]
Scope: broker
Related configs: listener.name.internal.max.connections.per.ip

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

max.connections.per.ip

brokermediumdynamic3.94.14.2

The maximum number of connections we allow from each ip address. This can be set to 0 if there are overrides configured using max.connections.per.ip.overrides property. New connections from the ip address are dropped if the limit is reached.

Default: 2147483647
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

max.connections.per.ip.overrides

brokermediumdynamic3.94.14.2

A comma-separated list of per-ip or hostname overrides to the default maximum number of connections. An example value is "hostName:100,127.0.0.1:200"

Default: ""
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

max.in.flight.requests.per.connection

clientlowdynamic3.94.14.2

The maximum number of unacknowledged requests the client will send on a single connection before blocking. Note that if this configuration is set to be greater than 1 and `enable.idempotence` is set to false, there is a risk of message reordering after a failed send due to retries (i.e., if retries are enabled); if retries are disabled or if `enable.idempotence` is set to true, ordering will be preserved. Additionally, enabling idempotence requires the value of this configuration to be less than or equal to 5, because broker only retains at most 5 batches for each producer. If the value is more than 5, previous batches may be removed on broker side.

Default: 5
Valid range: [1,...]
Scope: client
Related configs: enable.idempotence

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

max.incremental.fetch.session.cache.slots

brokermediumstatic3.94.14.2

The maximum number of total incremental fetch sessions that we will maintain. FetchSessionCache is sharded into 8 shards and the limit is equally divided among all shards. Sessions are allocated to each shard in round-robin. Only entries within a shard are considered eligible for eviction.

Default: 1000
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

max.message.bytes

topicmediumdynamic3.94.14.2

The largest record batch size allowed by Kafka (after compression if compression is enabled).

Default: 1048588
Valid range: [0,...]
Scope: topic
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

max.partition.fetch.bytes

clienthighdynamic3.94.14.2

The maximum amount of data per-partition the server will return. Records are fetched in batches by the consumer. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch will still be returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined via `message.max.bytes` (broker config) or `max.message.bytes` (topic config). See fetch.max.bytes for limiting the consumer request size.

Default: 1048576 (1 mebibyte)
Valid range: [0,...]
Scope: client
Related configs: message.max.bytes, max.message.bytes

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

max.poll.interval.ms

clientmediumdynamic3.94.14.2

The maximum delay between invocations of poll() when using consumer group management. This places an upper bound on the amount of time that the consumer can be idle before fetching more records. If poll() is not called before expiration of this timeout, then the consumer is considered failed and the group will rebalance in order to reassign the partitions to another member. For consumers using a non-null `group.instance.id` which reach this timeout, partitions will not be immediately reassigned. Instead, the consumer will stop sending heartbeats and partitions will be reassigned after expiration of the session timeout (defined by the client config `session.timeout.ms` if using the Classic rebalance protocol, or by the broker config `group.consumer.session.timeout.ms` if using the Consumer protocol). This mirrors the behavior of a static consumer which has shutdown.

Default: 300000 (5 minutes)
Valid range: [1,...]
Scope: client
Related configs: group.instance.id, session.timeout.ms, group.consumer.session.timeout.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

max.poll.records

clientmediumdynamic3.94.14.2

The maximum number of records returned in a single call to poll(). Note, that `max.poll.records` does not impact the underlying fetching behavior. The consumer will cache the records from each fetch request and returns them incrementally from each poll.

Default: 500
Valid range: [1,...]
Scope: client
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

max.request.partition.size.limit

brokermediumstatic3.94.14.2

The maximum number of partitions can be served in one request.

Default: 2000
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

max.request.size

clientmediumdynamic3.94.14.2

The maximum size of a request in bytes. This setting will limit the number of record batches the producer will send in a single request to avoid sending huge requests. This is also effectively a cap on the maximum uncompressed record batch size. Note that the server has its own cap on the record batch size (after compression if compression is enabled) which may be different from this.

Default: 1048576
Valid range: [0,...]
Scope: client
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

message.max.bytes

brokerhighdynamic3.94.14.2

The largest record batch size allowed by Kafka (after compression if compression is enabled).This can be set per topic with the topic level `max.message.bytes` config.

Default: 1048588
Valid range: [0,...]
Scope: broker
Related configs: max.message.bytes

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

message.timestamp.after.max.ms

topicmediumdynamic3.94.14.2

This configuration sets the allowable timestamp difference between the message timestamp and the broker's timestamp. The message timestamp can be later than or equal to the broker's timestamp, with the maximum allowable difference determined by the value set in this configuration. If message.timestamp.type=CreateTime, the message will be rejected if the difference in timestamps exceeds this specified threshold. This configuration is ignored if message.timestamp.type=LogAppendTime.

Default: 3600000 (1 hour)
Valid range: [0,...]
Scope: topic
Related configs

When you'd change it: Change this when the topic-level behavior needs to match the workload more closely. The use case is usually tuning retention, cleanup, message handling, or replication for a specific topic rather than the whole cluster.

message.timestamp.before.max.ms

topicmediumdynamic3.94.14.2

This configuration sets the allowable timestamp difference between the broker's timestamp and the message timestamp. The message timestamp can be earlier than or equal to the broker's timestamp, with the maximum allowable difference determined by the value set in this configuration. If message.timestamp.type=CreateTime, the message will be rejected if the difference in timestamps exceeds this specified threshold. This configuration is ignored if message.timestamp.type=LogAppendTime.

Default: 9223372036854775807
Valid range: [0,...]
Scope: topic
Related configs

When you'd change it: Change this when the topic-level behavior needs to match the workload more closely. The use case is usually tuning retention, cleanup, message handling, or replication for a specific topic rather than the whole cluster.

message.timestamp.type

topicmediumdynamic3.94.14.2

Define whether the timestamp in the message is message create time or log append time.

Default: CreateTime
Valid range: [CreateTime, LogAppendTime]
Scope: topic
Related configs

When you'd change it: Change this when the topic-level behavior needs to match the workload more closely. The use case is usually tuning retention, cleanup, message handling, or replication for a specific topic rather than the whole cluster.

metadata.log.dir

brokerhighstatic3.94.14.2

This configuration determines where we put the metadata log. If it is not set, the metadata log is placed in the first log directory from log.dirs.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

metadata.log.max.record.bytes.between.snapshots

brokerhighstatic3.94.14.2

This is the maximum number of bytes in the log between the latest snapshot and the high-watermark needed before generating a new snapshot. The default value is 20971520. To generate snapshots based on the time elapsed, see the `metadata.log.max.snapshot.interval.ms` configuration. The Kafka node will generate a snapshot when either the maximum time interval is reached or the maximum bytes limit is reached.

Default: 20971520
Valid range: [1,...]
Scope: broker
Related configs: metadata.log.max.snapshot.interval.ms

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

metadata.log.max.snapshot.interval.ms

brokerhighstatic3.94.14.2

This is the maximum number of milliseconds to wait to generate a snapshot if there are committed records in the log that are not included in the latest snapshot. A value of zero disables time based snapshot generation. The default value is 3600000. To generate snapshots based on the number of metadata bytes, see the `metadata.log.max.record.bytes.between.snapshots` configuration. The Kafka node will generate a snapshot when either the maximum time interval is reached or the maximum bytes limit is reached.

Default: 3600000 (1 hour)
Valid range: [0,...]
Scope: broker
Related configs: metadata.log.max.record.bytes.between.snapshots

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

metadata.log.segment.bytes

brokerhighstatic3.94.14.2

The maximum size of a single metadata log file.

Default: 1073741824 (1 gibibyte)
Valid range: [8388608,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

metadata.log.segment.ms

brokerhighstatic3.94.14.2

The maximum time before a new metadata log file is rolled out (in milliseconds).

Default: 604800000 (7 days)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

metadata.max.age.ms

clientlowdynamic3.94.14.2

The period of time in milliseconds after which we force a refresh of metadata even if we haven't seen any partition leadership changes to proactively discover any new brokers or partitions.

Default: 300000 (5 minutes)
Valid range: [0,...]
Scope: client
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

metadata.max.idle.interval.ms

brokerlowstatic3.94.14.2

This configuration controls how often the active controller should write no-op records to the metadata partition. If the value is 0, no-op records are not appended to the metadata partition. The default value is 500

Default: 500
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

metadata.max.idle.ms

clientlowdynamic3.94.14.2

Controls how long the producer will cache metadata for a topic that's idle. If the elapsed time since a topic was last produced to exceeds the metadata idle duration, then the topic's metadata is forgotten and the next access to it will force a metadata fetch request.

Default: 300000 (5 minutes)
Valid range: [5000,...]
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

metadata.max.retention.bytes

brokerhighstatic3.94.14.2

The maximum combined size of the metadata log and snapshots before deleting old snapshots and log files. Since at least one snapshot must exist before any logs can be deleted, this is a soft limit.

Default: 104857600 (100 mebibytes)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

metadata.max.retention.ms

brokerhighstatic3.94.14.2

The number of milliseconds to keep a metadata log file or snapshot before deleting it. Since at least one snapshot must exist before any logs can be deleted, this is a soft limit.

Default: 604800000 (7 days)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

metadata.recovery.rebootstrap.trigger.ms

clientlowdynamic4.14.2

If a client configured to rebootstrap using `metadata.recovery.strategy=rebootstrap` is unable to obtain metadata from any of the brokers in the last known metadata for this interval, client repeats the bootstrap process using `bootstrap.servers` configuration.

Default: 300000 (5 minutes)
Valid range: [0,...]
Scope: client
Related configs: bootstrap.servers

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

metadata.recovery.strategy

clientlowdynamic3.94.14.2

Controls how the client recovers when none of the brokers known to it is available. If set to `none`, the client fails. If set to `rebootstrap`, the client repeats the bootstrap process using `bootstrap.servers`. Rebootstrapping is useful when a client communicates with brokers so infrequently that the set of brokers may change entirely before the client refreshes metadata. Metadata recovery is triggered when all last-known brokers appear unavailable simultaneously. Brokers appear unavailable when disconnected and no current retry attempt is in-progress. Consider increasing `reconnect.backoff.ms` and `reconnect.backoff.max.ms` and decreasing `socket.connection.setup.timeout.ms` and `socket.connection.setup.timeout.max.ms` for the client. Rebootstrap is also triggered if connection cannot be established to any of the brokers for `metadata.recovery.rebootstrap.trigger.ms` milliseconds or if server requests rebootstrap.

Default: rebootstrap
Valid range: (case insensitive) [REBOOTSTRAP, NONE]
Scope: client
Related configs: bootstrap.servers, reconnect.backoff.ms, reconnect.backoff.max.ms, socket.connection.setup.timeout.ms, socket.connection.setup.timeout.max.ms, metadata.recovery.rebootstrap.trigger.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

metric.reporters

brokerlowdynamic3.94.14.2

A list of classes to use as metrics reporters. Implementing the `org.apache.kafka.common.metrics.MetricsReporter` interface allows plugging in classes that will be notified of new metric creation. When custom reporters are set and `org.apache.kafka.common.metrics.JmxReporter` is needed, it has to be explicitly added to the list.

Default: org.apache.kafka.common.metrics.JmxReporter
Valid range: A comma-separated list of values
Scope: broker
Related configs: org.apache.kafka.common.metrics.MetricsReporter, org.apache.kafka.common.metrics.JmxReporter

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

metrics.num.samples

brokerlowstatic3.94.14.2

The number of samples maintained to compute metrics.

Default: 2
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

metrics.recording.level

brokerlowstatic3.94.14.2

The highest recording level for metrics. It has three levels for recording metrics - info, debug, and trace. INFO level records only essential metrics necessary for monitoring system performance and health. It collects vital data without gathering too much detail, making it suitable for production environments where minimal overhead is desired. DEBUG level records most metrics, providing more detailed information about the system's operation. It's useful for development and testing environments where you need deeper insights to debug and fine-tune the application. TRACE level records all possible metrics, capturing every detail about the system's performance and operation. It's best for controlled environments where in-depth analysis is required, though it can introduce significant overhead.

Default: INFO
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

metrics.sample.window.ms

brokerlowstatic3.94.14.2

The window of time a metrics sample is computed over.

Default: 30000 (30 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

min.cleanable.dirty.ratio

topicmediumdynamic3.94.14.2

This configuration controls how frequently the log compactor will attempt to clean the log (assuming log compaction is enabled). By default we will avoid cleaning a log where more than 50% of the log has been compacted. This ratio bounds the maximum space wasted in the log by duplicates (at 50% at most 50% of the log could be duplicates). A higher ratio will mean fewer, more efficient cleanings but will mean more wasted space in the log. If the max.compaction.lag.ms or the min.compaction.lag.ms configurations are also specified, then the log compactor considers the log to be eligible for compaction as soon as either: (i) the dirty ratio threshold has been met and the log has had dirty (uncompacted) records for at least the min.compaction.lag.ms duration, or (ii) if the log has had dirty (uncompacted) records for at most the max.compaction.lag.ms period.

Default: 0.5
Valid range: [0,...,1]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

min.compaction.lag.ms

topicmediumdynamic3.94.14.2

The minimum time a message will remain uncompacted in the log. Only applicable for logs that are being compacted.

Default: 0
Valid range: [0,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

min.insync.replicas

brokerhighdynamic3.94.14.2

Specifies the minimum number of in-sync replicas (including the leader) required for a write to succeed when a producer sets `acks` to "all" (or "-1"). In the `acks=all` case, every in-sync replica must acknowledge a write for it to be considered successful. E.g., if a topic has `replication.factor` of 3 and the ISR set includes all three replicas, then all three replicas must acknowledge an `acks=all` write for it to succeed, even if `min.insync.replicas` happens to be less than 3. If `acks=all` and the current ISR set contains fewer than `min.insync.replicas` members, then the producer will raise an exception (either `NotEnoughReplicas` or `NotEnoughReplicasAfterAppend`). Regardless of the `acks` setting, the messages will not be visible to the consumers until they are replicated to all in-sync replicas and the `min.insync.replicas` condition is met. When used together, `min.insync.replicas` and `acks` allow you to enforce greater durability guarantees. A typical scenario would be to create a topic with a replication factor of 3, set `min.insync.replicas` to 2, and produce with `acks` of "all". This ensures that a majority of replicas must persist a write before it's considered successful by the producer and it's visible to consumers. Note that when the Eligible Leader Replicas feature is enabled, the semantics of this config changes. Please refer to the ELR section for more info.

Default: 1
Valid range: [1,...]
Scope: broker
Related configs: replication.factor

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

node.id

brokerhighstatic3.94.14.2

The node ID associated with the roles this process is playing when `process.roles` is non-empty. This is required configuration when running in KRaft mode.

Default: Not specified
Valid range: [0,...]
Scope: broker
Related configs: process.roles

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

num.io.threads

brokerhighdynamic3.94.14.2

The number of threads that the server uses for processing requests, which may include disk I/O

Default: 8
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

num.network.threads

brokerhighdynamic3.94.14.2

The number of threads that the server uses for receiving requests from the network and sending responses to the network. Noted: each listener (except for controller listener) creates its own thread pool.

Default: 3
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

num.partitions

brokermediumstatic3.94.14.2

The default number of log partitions per topic

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

num.recovery.threads.per.data.dir

brokerhighdynamic3.94.14.2

The number of threads per data directory to be used for log recovery at startup and flushing at shutdown

Default: 2
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

num.replica.alter.log.dirs.threads

brokerhighstatic3.94.14.2

The number of threads that can move replicas between log directories, which may include disk I/O. The default value is equal to the number of directories specified in the `log.dir` or `log.dirs` configuration property.

Default: null
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs: log.dir, log.dirs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

num.replica.fetchers

brokerhighdynamic3.94.14.2

Number of fetcher threads used to replicate records from each source broker. The total number of fetchers on each broker is bound by `num.replica.fetchers` multiplied by the number of brokers in the cluster.Increasing this value can increase the degree of I/O parallelism in the follower and leader broker at the cost of higher CPU and memory utilization.

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

offset.metadata.max.bytes

brokerhighstatic3.94.14.2

The maximum size for a metadata entry associated with an offset commit.

Default: 4096 (4 kibibytes)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

offsets.commit.timeout.ms

brokerhighstatic3.94.14.2

Offset commit will be delayed until all replicas for the offsets topic receive the commit or this timeout is reached. This is similar to the producer request timeout. This is applied to all the writes made by the coordinator.

Default: 5000 (5 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

offsets.load.buffer.size

brokerhighstatic3.94.14.2

Batch size for reading from the offsets segments when loading group metadata into the cache (soft-limit, overridden if records are too large).

Default: 5242880
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

offsets.retention.check.interval.ms

brokerhighstatic3.94.14.2

Frequency at which to check for stale offsets

Default: 600000 (10 minutes)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

offsets.retention.minutes

brokerhighstatic3.94.14.2

For subscribed consumers, committed offset of a specific partition will be expired and discarded when 1) this retention period has elapsed after the consumer group loses all its consumers (i.e. becomes empty); 2) this retention period has elapsed since the last time an offset is committed for the partition and the group is no longer subscribed to the corresponding topic. For standalone consumers (using manual assignment), offsets will be expired after this retention period has elapsed since the time of last commit. Note that when a group is deleted via the delete-group request, its committed offsets will also be deleted without extra retention period; also when a topic is deleted via the delete-topic request, upon propagated metadata update any group's committed offsets for that topic will also be deleted without extra retention period.

Default: 10080
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

offsets.topic.compression.codec

brokerhighstatic3.94.14.2

Compression codec for the offsets topic - compression may be used to achieve "atomic" commits.

Default: 0
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

offsets.topic.num.partitions

brokerhighstatic3.94.14.2

The number of partitions for the offset commit topic (should not change after deployment).

Default: 50
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

offsets.topic.replication.factor

brokerhighstatic3.94.14.2

The replication factor for the offsets topic (set higher to ensure availability). Internal topic creation will fail until the cluster size meets this replication factor requirement.

Default: 3
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

offsets.topic.segment.bytes

brokerhighstatic3.94.14.2

The offsets topic segment bytes should be kept relatively small in order to facilitate faster log compaction and cache loads.

Default: 104857600 (100 mebibytes)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

partition.assignment.strategy

clientmediumdynamic3.94.14.2

A list of class names or class types, ordered by preference, of supported partition assignment strategies that the client will use to distribute partition ownership amongst consumer instances when group management is used. Available options are: `org.apache.kafka.clients.consumer.RangeAssignor`: Assigns partitions on a per-topic basis. `org.apache.kafka.clients.consumer.RoundRobinAssignor`: Assigns partitions to consumers in a round-robin fashion. `org.apache.kafka.clients.consumer.StickyAssignor`: Guarantees an assignment that is maximally balanced while preserving as many existing partition assignments as possible. `org.apache.kafka.clients.consumer.CooperativeStickyAssignor`: Follows the same StickyAssignor logic, but allows for cooperative rebalancing. The default assignor is [RangeAssignor, CooperativeStickyAssignor], which will use the RangeAssignor by default, but allows upgrading to the CooperativeStickyAssignor with just a single rolling bounce that removes the RangeAssignor from the list. Implementing the `org.apache.kafka.clients.consumer.ConsumerPartitionAssignor` interface allows you to plug in a custom assignment strategy.

Default: class org.apache.kafka.clients.consumer.RangeAssignor,class org.apache.kafka.clients.consumer.CooperativeStickyAssignor
Valid range: A comma-separated list of values
Scope: client
Related configs: org.apache.kafka.clients.consumer.RangeAssignor, org.apache.kafka.clients.consumer.RoundRobinAssignor, org.apache.kafka.clients.consumer.StickyAssignor, org.apache.kafka.clients.consumer.CooperativeStickyAssignor, org.apache.kafka.clients.consumer.ConsumerPartitionAssignor

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

partitioner.adaptive.partitioning.enable

clientlowdynamic3.94.14.2

When set to 'true', the producer will try to adapt to broker performance and produce more messages to partitions hosted on faster brokers. If 'false', the producer will try to distribute messages uniformly. Note: this setting has no effect if a custom partitioner is used.

Default: true
Valid range: true or false
Scope: client
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

partitioner.availability.timeout.ms

clientlowdynamic3.94.14.2

If a broker cannot process produce requests from a partition for `partitioner.availability.timeout.ms` time, the partitioner treats that partition as not available. If the value is 0, this logic is disabled. Note: this setting has no effect if a custom partitioner is used or `partitioner.adaptive.partitioning.enable` is set to 'false'.

Default: 0
Valid range: [0,...]
Scope: client
Related configs: partitioner.adaptive.partitioning.enable

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

partitioner.class

clientmediumdynamic3.94.14.2

Determines which partition to send a record to when records are produced. Available options are: If not set, the default partitioning logic is used. This strategy send records to a partition until at least batch.size bytes is produced to the partition. It works with the strategy: If no partition is specified but a key is present, choose a partition based on a hash of the key. If no partition or key is present, choose the sticky partition that changes when at least batch.size bytes are produced to the partition. `org.apache.kafka.clients.producer.RoundRobinPartitioner`: A partitioning strategy where each record in a series of consecutive records is sent to a different partition, regardless of whether the 'key' is provided or not, until partitions run out and the process starts over again. Note: There's a known issue that will cause uneven distribution when a new batch is created. See KAFKA-9965 for more detail. Implementing the `org.apache.kafka.clients.producer.Partitioner` interface allows you to plug in a custom partitioner.

Default: null
Valid range: A fully qualified class name
Scope: client
Related configs: org.apache.kafka.clients.producer.RoundRobinPartitioner, org.apache.kafka.clients.producer.Partitioner

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

partitioner.ignore.keys

clientmediumdynamic3.94.14.2

When set to 'true' the producer won't use record keys to choose a partition. If 'false', producer would choose a partition based on a hash of the key when a key is present. Note: this setting has no effect if a custom partitioner is used.

Default: false
Valid range: true or false
Scope: client
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

preallocate

topicmediumdynamic3.94.14.2

True if we should preallocate the file on disk when creating a new log segment.

Default: false
Valid range: true or false
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

principal.builder.class

brokermediumdynamic3.94.14.2

The fully qualified name of a class that implements the KafkaPrincipalBuilder interface, which is used to build the KafkaPrincipal object used during authorization. If no principal builder is defined, the default behavior depends on the security protocol in use. For SSL authentication, the principal will be derived using the rules defined by `ssl.principal.mapping.rules` applied on the distinguished name from the client certificate if one is provided; otherwise, if client authentication is not required, the principal name will be ANONYMOUS. For SASL authentication, the principal will be derived using the rules defined by `sasl.kerberos.principal.to.local.rules` if GSSAPI is in use, and the SASL authentication ID for other mechanisms. For PLAINTEXT, the principal will be ANONYMOUS. Note that custom implementations of `KafkaPrincipalBuilder` is required to implement `KafkaPrincipalSerde` interface, otherwise brokers will not be able to forward requests to the controller.

Default: org.apache.kafka.common.security.authenticator.DefaultKafkaPrincipalBuilder
Valid range: A fully qualified class name
Scope: broker
Related configs: ssl.principal.mapping.rules, sasl.kerberos.principal.to.local.rules

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

process.roles

brokerhighstatic3.94.14.2

The roles that this process plays: 'broker', 'controller', or 'broker,controller' if it is both.

Default: Not specified
Valid range: [broker, controller]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

producer.id.expiration.ms

brokerlowdynamic3.94.14.2

The time in ms that a topic partition leader will wait before expiring producer IDs. Producer IDs will not expire while a transaction associated to them is still ongoing. Note that producer IDs may expire sooner if the last write from the producer ID is deleted due to the topic's retention settings. Setting this value the same or higher than `delivery.timeout.ms` can help prevent expiration during retries and protect against message duplication, but the default should be reasonable for most use cases.

Default: 86400000 (1 day)
Valid range: [1,...]
Scope: broker
Related configs: delivery.timeout.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

producer.purgatory.purge.interval.requests

brokermediumstatic3.94.14.2

The purge interval (in number of requests) of the producer request purgatory

Default: 1000
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

queued.max.request.bytes

brokermediumstatic3.94.14.2

The number of queued bytes allowed before no more requests are read

Default: -1
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

queued.max.requests

brokerhighstatic3.94.14.2

The number of queued requests allowed for data-plane, before blocking the network threads

Default: 500
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

quota.window.num

brokerlowstatic3.94.14.2

The number of samples to retain in memory for client quotas

Default: 11
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

quota.window.size.seconds

brokerlowstatic3.94.14.2

The time span of each sample for client quotas

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

receive.buffer.bytes

clientmediumdynamic3.94.14.2

The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default will be used.

Default: 32768 (32 kibibytes)
Valid range: [-1,...]
Scope: client
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

reconnect.backoff.max.ms

clientlowdynamic3.94.14.2

The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.

Default: 1000 (1 second)
Valid range: [0,...]
Scope: client
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

reconnect.backoff.ms

clientlowdynamic3.94.14.2

The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker. This value is the initial backoff value and will increase exponentially for each consecutive connection failure, up to the `reconnect.backoff.max.ms` value.

Default: 50
Valid range: [0,...]
Scope: client
Related configs: reconnect.backoff.max.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

remote.fetch.max.wait.ms

brokermediumdynamic3.94.14.2

The maximum amount of time the server will wait before answering the fetch request containing remote fetch partitions. It's important to be aware that the request will only be responded after all remote partitions have been successfully fetched, have failed, or this timeout is exceeded.

Default: 500
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

remote.list.offsets.request.timeout.ms

brokermediumdynamic4.14.2

The maximum amount of time the server will wait for the remote list offsets request to complete.

Default: 30000 (30 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

remote.log.copy.disable

topicmediumdynamic3.94.14.2

Determines whether tiered data for a topic should become read only, and no more data uploading on a topic. Once this config is set to true, the local retention configuration (i.e. local.retention.ms/bytes) becomes irrelevant, and all data expiration follows the topic-wide retention configuration(i.e. retention.ms/bytes).

Default: false
Valid range: true or false
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

remote.log.delete.on.disable

topicmediumdynamic3.94.14.2

Determines whether tiered data for a topic should be deleted after tiered storage is disabled on a topic. This configuration should be enabled when trying to set `remote.storage.enable` from true to false

Default: false
Valid range: true or false
Scope: topic
Related configs: remote.storage.enable

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

remote.log.index.file.cache.total.size.bytes

brokerlowdynamic3.94.14.2

The total size of the space allocated to store index files fetched from remote storage in the local storage.

Default: 1073741824 (1 gibibyte)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

remote.log.manager.copier.thread.pool.size

brokermediumdynamic3.94.14.2

Size of the thread pool used in scheduling tasks to copy segments.

Default: 10
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

remote.log.manager.copy.max.bytes.per.second

brokermediumdynamic3.94.14.2

The maximum number of bytes that can be copied from local storage to remote storage per second. This is a global limit for all the partitions that are being copied from local storage to remote storage. The default value is Long.MAX_VALUE, which means there is no limit on the number of bytes that can be copied per second.

Default: 9223372036854775807
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

remote.log.manager.copy.quota.window.num

brokermediumstatic3.94.14.2

The number of samples to retain in memory for remote copy quota management. The default value is 11, which means there are 10 whole windows + 1 current window.

Default: 11
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.log.manager.copy.quota.window.size.seconds

brokermediumstatic3.94.14.2

The time span of each sample for remote copy quota management. The default value is 1 second.

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

remote.log.manager.expiration.thread.pool.size

brokermediumdynamic3.94.14.2

Size of the thread pool used in scheduling tasks to clean up the expired remote log segments.

Default: 10
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

remote.log.manager.fetch.max.bytes.per.second

brokermediumdynamic3.94.14.2

The maximum number of bytes that can be fetched from remote storage to local storage per second. This is a global limit for all the partitions that are being fetched from remote storage to local storage. The default value is Long.MAX_VALUE, which means there is no limit on the number of bytes that can be fetched per second.

Default: 9223372036854775807
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

remote.log.manager.fetch.quota.window.num

brokermediumstatic3.94.14.2

The number of samples to retain in memory for remote fetch quota management. The default value is 11, which means there are 10 whole windows + 1 current window.

Default: 11
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.log.manager.fetch.quota.window.size.seconds

brokermediumstatic3.94.14.2

The time span of each sample for remote fetch quota management. The default value is 1 second.

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

remote.log.manager.follower.thread.pool.size

brokermediumdynamic4.2

Size of the thread pool used in scheduling follower tasks to read the highest-uploaded remote-offset for follower partitions.

Default: 2
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

remote.log.manager.task.interval.ms

brokerlowstatic3.94.14.2

Interval at which remote log manager runs the scheduled tasks like copy segments, and clean up remote log segments.

Default: 30000 (30 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

remote.log.manager.thread.pool.size

brokermediumstatic3.94.14.2

Size of the thread pool used in scheduling follower tasks to read the highest-uploaded remote-offset for follower partitions. This config is deprecated since 4.2, please use `remote.log.manager.follower.thread.pool.size` instead.

Default: 2
Valid range: [1,...]
Scope: broker
Related configs: remote.log.manager.follower.thread.pool.size

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

remote.log.metadata.custom.metadata.max.bytes

brokerlowstatic3.94.14.2

The maximum size of custom metadata in bytes that the broker should accept from a remote storage plugin. If custom metadata exceeds this limit, the updated segment metadata will not be stored, the copied data will be attempted to delete, and the remote copying task for this topic-partition will stop with an error.

Default: 128
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

remote.log.metadata.manager.class.name

brokermediumstatic3.94.14.2

Fully qualified class name of `RemoteLogMetadataManager` implementation.

Default: org.apache.kafka.server.log.remote.metadata.storage.TopicBasedRemoteLogMetadataManager
Valid range: non-empty string
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.log.metadata.manager.class.path

brokermediumstatic3.94.14.2

Class path of the `RemoteLogMetadataManager` implementation. If specified, the RemoteLogMetadataManager implementation and its dependent libraries will be loaded by a dedicated classloader which searches this class path before the Kafka broker class path. The syntax of this parameter is same as the standard Java class path string.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.log.metadata.manager.impl.prefix

brokermediumstatic3.94.14.2

Prefix used for properties to be passed to RemoteLogMetadataManager implementation. For example this value can be `rlmm.config.`.

Default: rlmm.config.
Valid range: non-empty string
Scope: broker
Related configs: rlmm.config.

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.log.metadata.manager.listener.name

brokermediumstatic3.94.14.2

Listener name of the local broker to which it should get connected if needed by RemoteLogMetadataManager implementation.

Default: null
Valid range: non-empty string
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

remote.log.reader.max.pending.tasks

brokermediumstatic3.94.14.2

Maximum remote log reader thread pool task queue size. If the task queue is full, fetch requests are served with an error.

Default: 100
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

remote.log.reader.threads

brokermediumdynamic3.94.14.2

Size of the thread pool that is allocated for handling remote log reads.

Default: 10
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

remote.log.storage.manager.class.name

brokermediumstatic3.94.14.2

Fully qualified class name of `RemoteStorageManager` implementation.

Default: null
Valid range: non-empty string
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.log.storage.manager.class.path

brokermediumstatic3.94.14.2

Class path of the `RemoteStorageManager` implementation. If specified, the RemoteStorageManager implementation and its dependent libraries will be loaded by a dedicated classloader which searches this class path before the Kafka broker class path. The syntax of this parameter is same as the standard Java class path string.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.log.storage.manager.impl.prefix

brokermediumstatic3.94.14.2

Prefix used for properties to be passed to RemoteStorageManager implementation. For example this value can be `rsm.config.`.

Default: rsm.config.
Valid range: non-empty string
Scope: broker
Related configs: rsm.config.

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.log.storage.system.enable

brokermediumstatic3.94.14.2

Whether to enable tiered storage functionality in a broker or not. When it is true broker starts all the services required for the tiered storage functionality.

Default: false
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

remote.storage.enable

topicmediumdynamic3.94.14.2

To enable tiered storage for a topic, set this configuration to true. To disable tiered storage for a topic that has it enabled, set this configuration to false. When disabling, you must also set `remote.log.delete.on.disable` to true.

Default: false
Valid range: true or false
Scope: topic
Related configs: remote.log.delete.on.disable

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

replica.fetch.backoff.ms

brokermediumstatic3.94.14.2

The amount of time to sleep when fetch partition error occurs.

Default: 1000 (1 second)
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

replica.fetch.max.bytes

brokermediumstatic3.94.14.2

The number of bytes of messages to attempt to fetch for each partition. This is not an absolute maximum, if the first record batch in the first non-empty partition of the fetch is larger than this value, the record batch will still be returned to ensure that progress can be made. The maximum record batch size accepted by the broker is defined via `message.max.bytes` (broker config) or `max.message.bytes` (topic config).

Default: 1048576 (1 mebibyte)
Valid range: [0,...]
Scope: broker
Related configs: message.max.bytes, max.message.bytes

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

replica.fetch.min.bytes

brokerhighstatic3.94.14.2

Minimum bytes expected for each fetch response. If not enough bytes, wait up to `replica.fetch.wait.max.ms` (broker config). Even if the total data available in the broker exceeds replica.fetch.min.bytes, the actual returned size may still be less than this value due to per-partition limits replica.fetch.max.bytes and max returned limits replica.fetch.response.max.bytes

Default: 1
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs: replica.fetch.wait.max.ms

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

replica.fetch.response.max.bytes

brokermediumstatic3.94.14.2

Maximum bytes expected for the entire fetch response. Records are fetched in batches, and if the first record batch in the first non-empty partition of the fetch is larger than this value, the record batch will still be returned to ensure that progress can be made. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined via `message.max.bytes` (broker config) or `max.message.bytes` (topic config).

Default: 10485760 (10 mebibytes)
Valid range: [0,...]
Scope: broker
Related configs: message.max.bytes, max.message.bytes

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

replica.fetch.wait.max.ms

brokerhighstatic3.94.14.2

The maximum wait time for each fetcher request issued by follower replicas. This value should always be less than the replica.lag.time.max.ms at all times to prevent frequent shrinking of ISR for low throughput topics

Default: 500
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

replica.high.watermark.checkpoint.interval.ms

brokerhighstatic3.94.14.2

The frequency with which the high watermark is saved out to disk

Default: 5000 (5 seconds)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

replica.lag.time.max.ms

brokerhighstatic3.94.14.2

If a follower hasn't sent any fetch requests or hasn't consumed up to the leader's log end offset for at least this time, the leader will remove the follower from ISR

Default: 30000 (30 seconds)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

replica.selector.class

brokermediumstatic3.94.14.2

The fully qualified class name that implements ReplicaSelector. This is used by the broker to find the preferred read replica. By default, we use an implementation that returns the leader.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

replica.socket.receive.buffer.bytes

brokerhighstatic3.94.14.2

The socket receive buffer for network requests to the leader for replicating data

Default: 65536 (64 kibibytes)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

replica.socket.timeout.ms

brokerhighstatic3.94.14.2

The socket timeout for network requests. Its value should be at least replica.fetch.wait.max.ms

Default: 30000 (30 seconds)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

replication.quota.window.num

brokerlowstatic3.94.14.2

The number of samples to retain in memory for replication quotas

Default: 11
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

replication.quota.window.size.seconds

brokerlowstatic3.94.14.2

The time span of each sample for replication quotas

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

request.timeout.ms

clientmediumdynamic3.94.14.2

The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted. This should be larger than `replica.lag.time.max.ms` (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.

Default: 30000 (30 seconds)
Valid range: [0,...]
Scope: client
Related configs: replica.lag.time.max.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

retention.bytes

topicmediumdynamic3.94.14.2

This configuration controls the maximum size a partition (which consists of log segments) can grow to before we will discard old log segments to free up space if we are using the "delete" retention policy. By default there is no size limit only a time limit. Since this limit is enforced at the partition level, multiply it by the number of partitions to compute the topic retention in bytes. Additionally, retention.bytes configuration operates independently of "segment.ms" and "segment.bytes" configurations. Moreover, it triggers the rolling of new segment if the retention.bytes is configured to zero.

Default: -1
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

retention.ms

topicmediumdynamic3.94.14.2

This configuration controls the maximum time we will retain a log before we will discard old log segments to free up space if we are using the "delete" retention policy. This represents an SLA on how soon consumers must read their data. If set to -1, no time limit is applied. Additionally, retention.ms configuration operates independently of "segment.ms" and "segment.bytes" configurations. Moreover, it triggers the rolling of new segment if the retention.ms condition is satisfied.

Default: 604800000 (7 days)
Valid range: [-1,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

retries

clienthighdynamic3.94.14.2

Number of times to retry a request that fails with a transient error. Setting a value greater than zero will cause the client to resend any record whose send fails with a potentially transient error. Requests will be retried this many times until they succeed, fail with a non-transient error, or the `delivery.timeout.ms` expires. Note that this automatic retry will simply resend the same record upon receiving the error. Setting a value of zero will disable this automatic retry behaviour, so that the transient errors will be propagated to the application to be handled. Users should generally prefer to leave this config unset and instead use `delivery.timeout.ms` to control retry behavior. Enabling idempotence requires this config value to be greater than 0. If conflicting configurations are set and idempotence is not explicitly enabled, idempotence is disabled. Allowing retries while setting `enable.idempotence` to `false` and `max.in.flight.requests.per.connection` to greater than 1 will potentially change the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch may appear first.

Default: 2147483647
Valid range: [0,...,2147483647]
Scope: client
Related configs: delivery.timeout.ms, enable.idempotence, max.in.flight.requests.per.connection

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

retry.backoff.max.ms

clientlowdynamic3.94.14.2

The maximum amount of time in milliseconds to wait when retrying a request to the broker that has repeatedly failed. If provided, the backoff per client will increase exponentially for each failed request, up to this maximum. To prevent all clients from being synchronized upon retry, a randomized jitter with a factor of 0.2 will be applied to the backoff, resulting in the backoff falling within a range between 20% below and 20% above the computed value. If `retry.backoff.ms` is set to be higher than `retry.backoff.max.ms`, then `retry.backoff.max.ms` will be used as a constant backoff from the beginning without any exponential increase

Default: 1000 (1 second)
Valid range: [0,...]
Scope: client
Related configs: retry.backoff.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

retry.backoff.ms

clientlowdynamic3.94.14.2

The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios. This value is the initial backoff value and will increase exponentially for each failed request, up to the `retry.backoff.max.ms` value.

Default: 100
Valid range: [0,...]
Scope: client
Related configs: retry.backoff.max.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

sasl.client.callback.handler.class

brokermediumstatic3.94.14.2

The fully qualified name of a SASL client callback handler class that implements the AuthenticateCallbackHandler interface.

Default: null
Valid range: A fully qualified class name
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.enabled.mechanisms

brokermediumdynamic3.94.14.2

The list of SASL mechanisms enabled in the Kafka server. The list may contain any mechanism for which a security provider is available. Only GSSAPI is enabled by default.

Default: GSSAPI
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.jaas.config

brokermediumdynamic3.94.14.2

JAAS login context parameters for SASL connections in the format used by JAAS configuration files. JAAS configuration file format is described here . The format for the value is: `loginModuleClass controlFlag (optionName=optionValue)*;`. For brokers, the config must be prefixed with listener prefix and SASL mechanism name in lower-case. For example, listener.name.sasl_ssl.scram-sha-256.sasl.jaas.config=com.example.ScramLoginModule required;

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

sasl.kerberos.kinit.cmd

brokermediumdynamic3.94.14.2

Kerberos kinit command path.

Default: /usr/bin/kinit
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.kerberos.min.time.before.relogin

brokermediumdynamic3.94.14.2

Login thread sleep time between refresh attempts.

Default: 60000
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.kerberos.principal.to.local.rules

brokermediumdynamic3.94.14.2

A list of rules for mapping from principal names to short names (typically operating system usernames). The rules are evaluated in order and the first rule that matches a principal name is used to map it to a short name. Any later rules in the list are ignored. By default, principal names of the form `{username}/{hostname}@{REALM}` are mapped to `{username}`. For more details on the format please see security authorization and acls . Note that this configuration is ignored if an extension of `KafkaPrincipalBuilder` is provided by the `principal.builder.class` configuration.

Default: DEFAULT
Valid range: A comma-separated list of values
Scope: broker
Related configs: principal.builder.class

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.kerberos.service.name

brokermediumdynamic3.94.14.2

The Kerberos principal name that Kafka runs as. This can be defined either in Kafka's JAAS config or in Kafka's config.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.kerberos.ticket.renew.jitter

brokermediumdynamic3.94.14.2

Percentage of random jitter added to the renewal time.

Default: 0.05
Valid range: Any valid decimal number unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.kerberos.ticket.renew.window.factor

brokermediumdynamic3.94.14.2

Login thread will sleep until the specified window factor of time from last refresh to ticket's expiry has been reached, at which time it will try to renew the ticket.

Default: 0.8
Valid range: Any valid decimal number unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.login.callback.handler.class

brokermediumstatic3.94.14.2

The fully qualified name of a SASL login callback handler class that implements the AuthenticateCallbackHandler interface. For brokers, login callback handler config must be prefixed with listener prefix and SASL mechanism name in lower-case. For example, listener.name.sasl_ssl.scram-sha-256.sasl.login.callback.handler.class=com.example.CustomScramLoginCallbackHandler

Default: null
Valid range: A fully qualified class name
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.login.class

brokermediumstatic3.94.14.2

The fully qualified name of a class that implements the Login interface. For brokers, login config must be prefixed with listener prefix and SASL mechanism name in lower-case. For example, listener.name.sasl_ssl.scram-sha-256.sasl.login.class=com.example.CustomScramLogin

Default: null
Valid range: A fully qualified class name
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.login.connect.timeout.ms

brokerlowstatic3.94.14.2

The (optional) value in milliseconds for the external authentication provider connection timeout. Currently applies only to OAUTHBEARER.

Default: null
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

sasl.login.read.timeout.ms

brokerlowstatic3.94.14.2

The (optional) value in milliseconds for the external authentication provider read timeout. Currently applies only to OAUTHBEARER.

Default: null
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

sasl.login.refresh.buffer.seconds

brokermediumdynamic3.94.14.2

The amount of buffer time before credential expiration to maintain when refreshing a credential, in seconds. If a refresh would otherwise occur closer to expiration than the number of buffer seconds then the refresh will be moved up to maintain as much of the buffer time as possible. Legal values are between 0 and 3600 (1 hour); a default value of 300 (5 minutes) is used if no value is specified. This value and sasl.login.refresh.min.period.seconds are both ignored if their sum exceeds the remaining lifetime of a credential. Currently applies only to OAUTHBEARER.

Default: 300
Valid range: Any valid short integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.login.refresh.min.period.seconds

brokermediumdynamic3.94.14.2

The desired minimum time for the login refresh thread to wait before refreshing a credential, in seconds. Legal values are between 0 and 900 (15 minutes); a default value of 60 (1 minute) is used if no value is specified. This value and sasl.login.refresh.buffer.seconds are both ignored if their sum exceeds the remaining lifetime of a credential. Currently applies only to OAUTHBEARER.

Default: 60
Valid range: Any valid short integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.login.refresh.window.factor

brokermediumdynamic3.94.14.2

Login refresh thread will sleep until the specified window factor relative to the credential's lifetime has been reached, at which time it will try to refresh the credential. Legal values are between 0.5 (50%) and 1.0 (100%) inclusive; a default value of 0.8 (80%) is used if no value is specified. Currently applies only to OAUTHBEARER.

Default: 0.8
Valid range: Any valid decimal number unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.login.refresh.window.jitter

brokermediumdynamic3.94.14.2

The maximum amount of random jitter relative to the credential's lifetime that is added to the login refresh thread's sleep time. Legal values are between 0 and 0.25 (25%) inclusive; a default value of 0.05 (5%) is used if no value is specified. Currently applies only to OAUTHBEARER.

Default: 0.05
Valid range: Any valid decimal number unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.login.retry.backoff.max.ms

brokerlowstatic3.94.14.2

The (optional) value in milliseconds for the maximum wait between login attempts to the external authentication provider. Login uses an exponential backoff algorithm with an initial wait based on the sasl.login.retry.backoff.ms setting and will double in wait length between attempts up to a maximum wait length specified by the sasl.login.retry.backoff.max.ms setting. Currently applies only to OAUTHBEARER.

Default: 10000 (10 seconds)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

sasl.login.retry.backoff.ms

brokerlowstatic3.94.14.2

The (optional) value in milliseconds for the initial wait between login attempts to the external authentication provider. Login uses an exponential backoff algorithm with an initial wait based on the sasl.login.retry.backoff.ms setting and will double in wait length between attempts up to a maximum wait length specified by the sasl.login.retry.backoff.max.ms setting. Currently applies only to OAUTHBEARER.

Default: 100
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

sasl.mechanism

clientmediumdynamic3.94.14.2

SASL mechanism used for client connections. This may be any mechanism for which a security provider is available. GSSAPI is the default mechanism.

Default: GSSAPI
Valid range: Any valid string value
Scope: client
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

sasl.mechanism.controller.protocol

brokerhighstatic3.94.14.2

SASL mechanism used for communication with controllers. Default is GSSAPI.

Default: GSSAPI
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.mechanism.inter.broker.protocol

brokermediumdynamic3.94.14.2

SASL mechanism used for inter-broker communication. Default is GSSAPI.

Default: GSSAPI
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.algorithm

brokermediumstatic4.14.2

The algorithm the Apache Kafka client should use to sign the assertion sent to the identity provider. It is also used as the value of the OAuth `alg` (Algorithm) header in the JWT assertion. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: RS256
Valid range: (case insensitive) [ES256, RS256]
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.claim.aud

brokermediumstatic4.14.2

The JWT `aud` (Audience) claim which will be included in the client JWT assertion created locally. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.claim.exp.seconds

brokerlowstatic4.14.2

The number of seconds in the future for which the JWT is valid. The value is used to determine the JWT `exp` (Expiration) claim based on the current system time when the JWT is created. The formula to generate the `exp` claim is very simple: Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: 300
Valid range: [0,...,86400]
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.claim.iss

brokermediumstatic4.14.2

The value to be used as the `iss` (Issuer) claim which will be included in the client JWT assertion created locally. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.claim.jti.include

brokermediumstatic4.14.2

Flag that determines if the JWT assertion should generate a unique ID for the JWT and include it in the `jti` (JWT ID) claim. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: false
Valid range: true or false
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.claim.nbf.seconds

brokerlowstatic4.14.2

The number of seconds in the past from which the JWT is valid. The value is used to determine the JWT `nbf` (Not Before) claim based on the current system time when the JWT is created. The formula to generate the `nbf` claim is very simple: Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: 60
Valid range: [0,...,3600]
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.claim.sub

brokermediumstatic4.14.2

The value to be used as the `sub` (Subject) claim which will be included in the client JWT assertion created locally. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.file

brokermediumstatic4.14.2

File that contains a pre-generated JWT assertion. The underlying implementation caches the file contents to avoid the performance hit of loading the file on each access. The caching mechanism will detect whenthe file changes to allow for the file to be reloaded on modifications. This allows for "live" assertion rotation without restarting the Kafka client. The file contains the assertion in the serialized, three part JWT format: The header section is a base 64-encoded JWT header that contains values like `alg` (Algorithm), `typ` (Type, always the literal value `JWT`), etc. The payload section includes the base 64-encoded set of JWT claims, such as `aud` (Audience), `iss` (Issuer), `sub` (Subject), etc. The signature section is the concatenated header and payload sections that was signed using a private key See RFC 7519 and RFC 7515 for more details on the JWT and JWS formats. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, all other `sasl.oauthbearer.assertion.`* configurations are ignored.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.oauthbearer.assertion.

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.private.key.file

brokermediumstatic4.14.2

File that contains a private key in the standard PEM format which is used to sign the JWT assertion sent to the identity provider. The underlying implementation caches the file contents to avoid the performance hit of loading the file on each access. The caching mechanism will detect when the file changes to allow for the file to be reloaded on modifications. This allows for "live" private key rotation without restarting the Kafka client. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.private.key.passphrase

brokermediumstatic4.14.2

The optional passphrase to decrypt the private key file specified by `sasl.oauthbearer.assertion.private.key.file`. Note : If the file referred to by `sasl.oauthbearer.assertion.private.key.file` is modified on the file system at runtime and it was created with a different passphrase than it was previously, the client will not be able to access the private key file because the passphrase is now out of date. For that reason, when using private key passphrases, either use the same passphrase each time, or—for improved security—restart the Kafka client using the new passphrase configuration. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs: sasl.oauthbearer.assertion.private.key.file, sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.assertion.template.file

brokermediumstatic4.14.2

This optional configuration specifies the file containing the JWT headers and/or payload claims to be used when creating the JWT assertion. Not all identity providers require the same set of claims; some may require a given claim while others may prohibit it. In order to provide the most flexibility, this configuration allows the user to provide the static header values and claims that are to be included in the JWT. Note : If a value for `sasl.oauthbearer.assertion.file` is provided, this configuration will be ignored.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.oauthbearer.assertion.file

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.client.credentials.client.id

brokermediumstatic4.14.2

The ID (defined in/by the OAuth identity provider) to identify the client requesting the token. The client ID was previously stored as part of the `sasl.jaas.config` configuration with the key `clientId`. For backward compatibility, the `clientId` JAAS option can still be used, but it is deprecated and will be removed in a future version. Order of precedence: `sasl.oauthbearer.client.credentials.client.id` from configuration `clientId` from JAAS

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.jaas.config

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.client.credentials.client.secret

brokermediumstatic4.14.2

The secret (defined by either the user or preassigned, depending on the identity provider) of the client requesting the token. The client secret was previously stored as part of the `sasl.jaas.config` configuration with the key `clientSecret`. For backward compatibility, the `clientSecret` JAAS option can still be used, but it is deprecated and will be removed in a future version. Order of precedence: `sasl.oauthbearer.client.credentials.client.secret` from configuration `clientSecret` from JAAS

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs: sasl.jaas.config

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.clock.skew.seconds

brokerlowstatic3.94.14.2

The (optional) value in seconds to allow for differences between the time of the OAuth/OIDC identity provider and the broker.

Default: 30
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.expected.audience

brokerlowstatic3.94.14.2

The (optional) comma-delimited setting for the broker to use to verify that the JWT was issued for one of the expected audiences. The JWT will be inspected for the standard OAuth "aud" claim and if this value is set, the broker will match the value from JWT's "aud" claim to see if there is an exact match. If there is no match, the broker will reject the JWT and authentication will fail.

Default: ""
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.expected.issuer

brokerlowstatic3.94.14.2

The (optional) setting for the broker to use to verify that the JWT was created by the expected issuer. The JWT will be inspected for the standard OAuth "iss" claim and if this value is set, the broker will match it exactly against what is in the JWT's "iss" claim. If there is no match, the broker will reject the JWT and authentication will fail.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.header.urlencode

clientlowdynamic3.94.14.2

The (optional) setting to enable the OAuth client to URL-encode the client_id and client_secret in the authorization header in accordance with RFC6749, see here for more details. The default value is set to 'false' for backward compatibility

Default: false
Valid range: true or false
Scope: client
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.jwks.endpoint.refresh.ms

brokerlowstatic3.94.14.2

The (optional) value in milliseconds for the broker to wait between refreshing its JWKS (JSON Web Key Set) cache that contains the keys to verify the signature of the JWT.

Default: 3600000 (1 hour)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms

brokerlowstatic3.94.14.2

The (optional) value in milliseconds for the maximum wait between attempts to retrieve the JWKS (JSON Web Key Set) from the external authentication provider. JWKS retrieval uses an exponential backoff algorithm with an initial wait based on the sasl.oauthbearer.jwks.endpoint.retry.backoff.ms setting and will double in wait length between attempts up to a maximum wait length specified by the sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms setting.

Default: 10000 (10 seconds)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

sasl.oauthbearer.jwks.endpoint.retry.backoff.ms

brokerlowstatic3.94.14.2

The (optional) value in milliseconds for the initial wait between JWKS (JSON Web Key Set) retrieval attempts from the external authentication provider. JWKS retrieval uses an exponential backoff algorithm with an initial wait based on the sasl.oauthbearer.jwks.endpoint.retry.backoff.ms setting and will double in wait length between attempts up to a maximum wait length specified by the sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms setting.

Default: 100
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

sasl.oauthbearer.jwks.endpoint.url

brokermediumstatic3.94.14.2

The OAuth/OIDC provider URL from which the provider's JWKS (JSON Web Key Set) can be retrieved. The URL can be HTTP(S)-based or file-based. If the URL is HTTP(S)-based, the JWKS data will be retrieved from the OAuth/OIDC provider via the configured URL on broker startup. All then-current keys will be cached on the broker for incoming requests. If an authentication request is received for a JWT that includes a "kid" header claim value that isn't yet in the cache, the JWKS endpoint will be queried again on demand. However, the broker polls the URL every sasl.oauthbearer.jwks.endpoint.refresh.ms milliseconds to refresh the cache with any forthcoming keys before any JWT requests that include them are received. If the URL is file-based, the broker will load the JWKS file from a configured location on startup. In the event that the JWT includes a "kid" header value that isn't in the JWKS file, the broker will reject the JWT and authentication will fail.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.jwt.retriever.class

brokermediumstatic4.14.2

The fully-qualified class name of a `JwtRetriever` implementation used to request tokens from the identity provider. The default configuration value represents a class that maintains backward compatibility with previous versions of Apache Kafka. The default implementation uses the configuration to determine which concrete implementation to create. Other implementations that are provided include: `org.apache.kafka.common.security.oauthbearer.ClientCredentialsJwtRetriever` `org.apache.kafka.common.security.oauthbearer.DefaultJwtRetriever` `org.apache.kafka.common.security.oauthbearer.FileJwtRetriever` `org.apache.kafka.common.security.oauthbearer.JwtBearerJwtRetriever`

Default: org.apache.kafka.common.security.oauthbearer.DefaultJwtRetriever
Valid range: A fully qualified class name
Scope: broker
Related configs: org.apache.kafka.common.security.oauthbearer.ClientCredentialsJwtRetriever, org.apache.kafka.common.security.oauthbearer.DefaultJwtRetriever, org.apache.kafka.common.security.oauthbearer.FileJwtRetriever, org.apache.kafka.common.security.oauthbearer.JwtBearerJwtRetriever

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.jwt.validator.class

brokermediumstatic4.14.2

The fully-qualified class name of a `JwtValidator` implementation used to validate the JWT from the identity provider. The default validator (`org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator`) maintains backward compatibility with previous versions of Apache Kafka. The default validator uses configuration to determine which concrete implementation to create. The built-in `JwtValidator` implementations are: `org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator` `org.apache.kafka.common.security.oauthbearer.ClientJwtValidator` `org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator`

Default: org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator
Valid range: A fully qualified class name
Scope: broker
Related configs: org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator, org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator, org.apache.kafka.common.security.oauthbearer.ClientJwtValidator

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.scope

brokermediumstatic4.14.2

This is the level of access a client application is granted to a resource or API which is included in the token request. If provided, it should match one or more scopes configured in the identity provider. The scope was previously stored as part of the `sasl.jaas.config` configuration with the key `scope`. For backward compatibility, the `scope` JAAS option can still be used, but it is deprecated and will be removed in a future version. Order of precedence: `sasl.oauthbearer.scope` from configuration `scope` from JAAS

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.jaas.config

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.scope.claim.name

brokerlowstatic3.94.14.2

The OAuth claim for the scope is often named "scope", but this (optional) setting can provide a different name to use for the scope included in the JWT payload's claims if the OAuth/OIDC provider uses a different name for that claim.

Default: scope
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.sub.claim.name

brokerlowstatic3.94.14.2

The OAuth claim for the subject is often named "sub", but this (optional) setting can provide a different name to use for the subject included in the JWT payload's claims if the OAuth/OIDC provider uses a different name for that claim.

Default: sub
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.oauthbearer.token.endpoint.url

brokermediumstatic3.94.14.2

The URL for the OAuth/OIDC identity provider. If the URL is HTTP(S)-based, it is the issuer's token endpoint URL to which requests will be made to login based on the configuration in `sasl.oauthbearer.jwt.retriever.class`. If the URL is file-based, it specifies a file containing an access token (in JWT serialized form) issued by the OAuth/OIDC identity provider to use for authorization.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: sasl.oauthbearer.jwt.retriever.class

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.server.callback.handler.class

brokermediumstatic3.94.14.2

The fully qualified name of a SASL server callback handler class that implements the AuthenticateCallbackHandler interface. Server callback handlers must be prefixed with listener prefix and SASL mechanism name in lower-case. For example, listener.name.sasl_ssl.plain.sasl.server.callback.handler.class=com.example.CustomPlainCallbackHandler.

Default: null
Valid range: A fully qualified class name
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

sasl.server.max.receive.size

brokermediumstatic3.94.14.2

The maximum receive size allowed before and during initial SASL authentication. Default receive size is 512KB. GSSAPI limits requests to 64K, but we allow upto 512KB by default for custom SASL mechanisms. In practice, PLAIN, SCRAM and OAUTH mechanisms can use much smaller limits.

Default: 524288
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

security.inter.broker.protocol

brokermediumstatic3.94.14.2

Security protocol used to communicate between brokers. It is an error to set this and inter.broker.listener.name properties at the same time.

Default: PLAINTEXT
Valid range: [PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL]
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

security.protocol

clientmediumdynamic3.94.14.2

Protocol used to communicate with brokers.

Default: PLAINTEXT
Valid range: (case insensitive) [SASL_SSL, PLAINTEXT, SSL, SASL_PLAINTEXT]
Scope: client
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

security.providers

brokerlowstatic3.94.14.2

A list of configurable creator classes each returning a provider implementing security algorithms. These classes should implement the `org.apache.kafka.common.security.auth.SecurityProviderCreator` interface.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs: org.apache.kafka.common.security.auth.SecurityProviderCreator

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

segment.bytes

topicmediumdynamic3.94.14.2

This configuration controls the segment file size for the log. Retention and cleaning is always done a file at a time so a larger segment size means fewer files but less granular control over retention.

Default: 1073741824 (1 gibibyte)
Valid range: [1048576,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

segment.index.bytes

topicmediumdynamic3.94.14.2

This configuration controls the size of the index that maps offsets to file positions. We preallocate this index file and shrink it only after log rolls. You generally should not need to change this setting.

Default: 10485760 (10 mebibytes)
Valid range: [4,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

segment.jitter.ms

topicmediumdynamic3.94.14.2

The maximum random jitter subtracted from the scheduled segment roll time to avoid thundering herds of segment rolling

Default: 0
Valid range: [0,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

segment.ms

topicmediumdynamic3.94.14.2

This configuration controls the period of time after which Kafka will force the log to roll even if the segment file isn't full to ensure that retention can delete or compact old data.

Default: 604800000 (7 days)
Valid range: [1,...]
Scope: topic
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

send.buffer.bytes

clientmediumdynamic3.94.14.2

The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default will be used.

Default: 131072 (128 kibibytes)
Valid range: [-1,...]
Scope: client
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

session.timeout.ms

clienthighdynamic3.94.14.2

The timeout used to detect client failures when using Kafka's group management facility. The client sends periodic heartbeats to indicate its liveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker will remove this client from the group and initiate a rebalance. Note that the value must be in the allowable range as configured in the broker configuration by `group.min.session.timeout.ms` and `group.max.session.timeout.ms`. Note that this client configuration is not supported when `group.protocol` is set to "consumer". In that case, session timeout is controlled by the broker config `group.consumer.session.timeout.ms`.

Default: 45000 (45 seconds)
Valid range: Any valid integer unless constrained elsewhere
Scope: client
Related configs: group.min.session.timeout.ms, group.max.session.timeout.ms, group.protocol, group.consumer.session.timeout.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

share.acknowledgement.mode

clientmediumdynamic4.14.2

Controls the acknowledgement mode for a share consumer. If set to `implicit`, the acknowledgement mode of the consumer is implicit and it must not use `org.apache.kafka.clients.consumer.ShareConsumer.acknowledge()` to acknowledge delivery of records. Instead, delivery is acknowledged implicitly on the next call to poll or commit. If set to `explicit`, the acknowledgement mode of the consumer is explicit and it must use `org.apache.kafka.clients.consumer.ShareConsumer.acknowledge()` to acknowledge delivery of records.

Default: implicit
Valid range: [implicit, explicit]
Scope: client
Related configs

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

share.acquire.mode

clientmediumdynamic4.2

Controls the acquire mode for a share consumer. If set to `record_limit`, the number of records returned in each poll() will not exceed the value of `max.poll.records`. If set to `batch_optimized`, the number of records returned in each poll() call may exceed `max.poll.records` to align with batch boundaries for optimization.

Default: BATCH_OPTIMIZED
Valid range: [batch_optimized, record_limit]
Scope: client
Related configs: max.poll.records

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

share.coordinator.append.linger.ms

brokermediumstatic4.14.2

The duration in milliseconds that the share coordinator will wait for writes to accumulate before flushing them to disk. Set to -1 for an adaptive linger time that minimizes latency based on the workload.

Default: -1
Valid range: [-1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

share.coordinator.load.buffer.size

brokerhighstatic4.14.2

Batch size for reading from the share-group state topic when loading state information into the cache (soft-limit, overridden if records are too large).

Default: 5242880
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

share.coordinator.snapshot.update.records.per.snapshot

brokermediumstatic4.14.2

The number of update records the share coordinator writes between snapshot records.

Default: 500
Valid range: [0,...]
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

share.coordinator.state.topic.compression.codec

brokerhighstatic4.14.2

Compression codec for the share-group state topic.

Default: 0
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

share.coordinator.state.topic.min.isr

brokerhighstatic4.14.2

Overridden min.insync.replicas for the share-group state topic.

Default: 2
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

share.coordinator.state.topic.num.partitions

brokerhighstatic4.14.2

The number of partitions for the share-group state topic (should not change after deployment).

Default: 50
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control parallelism, ordering scope, or how much work a topic can spread across producers and consumers. The use case is usually scale planning rather than a one-off functional fix.

share.coordinator.state.topic.replication.factor

brokerhighstatic4.14.2

Replication factor for the share-group state topic. Topic creation will fail until the cluster size meets this replication factor requirement.

Default: 3
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

share.coordinator.state.topic.segment.bytes

brokerhighstatic4.14.2

The log segment size for the share-group state topic.

Default: 104857600 (100 mebibytes)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

share.coordinator.threads

brokermediumstatic4.14.2

The number of threads used by the share coordinator.

Default: 1
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

share.coordinator.write.timeout.ms

brokerhighstatic4.14.2

The duration in milliseconds that the share coordinator will wait for all replicas of the share-group state topic to receive a write.

Default: 5000 (5 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

share.fetch.purgatory.purge.interval.requests

brokermediumstatic4.14.2

The purge interval (in number of requests) of the share fetch request purgatory

Default: 1000
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when the broker defaults no longer match how the cluster is operated. The use case is usually durability, scaling, security, or controlling how all new workloads behave by default.

socket.connection.setup.timeout.max.ms

brokermediumstatic3.94.14.2

The maximum amount of time the client will wait for the socket connection to be established. The connection setup timeout will increase exponentially for each consecutive connection failure up to this maximum. To avoid connection storms, a randomization factor of 0.2 will be applied to the timeout resulting in a random range between 20% below and 20% above the computed value.

Default: 30000 (30 seconds)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

socket.connection.setup.timeout.ms

brokermediumstatic3.94.14.2

The amount of time the client will wait for the socket connection to be established. If the connection is not built before the timeout elapses, clients will close the socket channel. This value is the initial backoff value and will increase exponentially for each consecutive connection failure, up to the `socket.connection.setup.timeout.max.ms` value.

Default: 10000 (10 seconds)
Valid range: Any valid 64-bit integer unless constrained elsewhere
Scope: broker
Related configs: socket.connection.setup.timeout.max.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

socket.listen.backlog.size

brokermediumstatic3.94.14.2

The maximum number of pending connections on the socket. In Linux, you may also need to configure `somaxconn` and `tcp_max_syn_backlog` kernel parameters accordingly to make the configuration takes effect.

Default: 50
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

socket.receive.buffer.bytes

brokerhighstatic3.94.14.2

The SO_RCVBUF buffer of the socket server sockets. If the value is -1, the OS default will be used.

Default: 102400 (100 kibibytes)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

socket.request.max.bytes

brokerhighstatic3.94.14.2

The maximum number of bytes in a socket request

Default: 104857600 (100 mebibytes)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

socket.send.buffer.bytes

brokerhighstatic3.94.14.2

The SO_SNDBUF buffer of the socket server sockets. If the value is -1, the OS default will be used.

Default: 102400 (100 kibibytes)
Valid range: Any valid integer unless constrained elsewhere
Scope: broker
Related configs

When you'd change it: Change this when message size, fetch size, or memory pressure becomes the real constraint. The use case is typically larger payloads, high-throughput topics, or avoiding failures caused by request and fetch limits that do not line up.

ssl.allow.dn.changes

brokerlowstatic3.94.14.2

Indicates whether changes to the certificate distinguished name should be allowed during a dynamic reconfiguration of certificates or not.

Default: false
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.allow.san.changes

brokerlowstatic3.94.14.2

Indicates whether changes to the certificate subject alternative names should be allowed during a dynamic reconfiguration of certificates or not.

Default: false
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.cipher.suites

brokermediumdynamic3.94.14.2

A list of cipher suites. This is a named combination of authentication, encryption, MAC and key exchange algorithm used to negotiate the security settings for a network connection using TLS or SSL network protocol. By default all the available cipher suites are supported.

Default: ""
Valid range: A comma-separated list of values
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.client.auth

brokermediumdynamic3.94.14.2

Configures kafka broker to request client authentication. The following settings are common: `ssl.client.auth=required` If set to required client authentication is required. `ssl.client.auth=requested` This means client authentication is optional. unlike required, if this option is set client can choose not to provide authentication information about itself `ssl.client.auth=none` This means client authentication is not needed.

Default: none
Valid range: [required, requested, none]
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.enabled.protocols

brokermediumdynamic3.94.14.2

The list of protocols enabled for SSL connections. The default is 'TLSv1.2,TLSv1.3'. This means that clients and servers will prefer TLSv1.3 if both support it and fallback to TLSv1.2 otherwise (assuming both support at least TLSv1.2). This default should be fine for most use cases. If this configuration is set to an empty list, Kafka will use the protocols enabled by default in the underlying SSLEngine, which may include additional protocols depending on the JVM version. Also see the config documentation for `ssl.protocol` to understand how it can impact the TLS version negotiation behavior.

Default: TLSv1.2,TLSv1.3
Valid range: A comma-separated list of values
Scope: broker
Related configs: ssl.protocol

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

ssl.endpoint.identification.algorithm

brokerlowdynamic3.94.14.2

The endpoint identification algorithm to validate server hostname using server certificate.

Default: https
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.engine.factory.class

brokerlowdynamic3.94.14.2

The class of type org.apache.kafka.common.security.auth.SslEngineFactory to provide SSLEngine objects. Default value is org.apache.kafka.common.security.ssl.DefaultSslEngineFactory. Alternatively, setting this to org.apache.kafka.common.security.ssl.CommonNameLoggingSslEngineFactory will log the common name of expired SSL certificates used by clients to authenticate at any of the brokers with log level INFO. Note that this will cause a tiny delay during establishment of new connections from mTLS clients to brokers due to the extra code for examining the certificate chain provided by the client. Note further that the implementation uses a custom truststore based on the standard Java truststore and thus might be considered a security risk due to not being as mature as the standard one.

Default: null
Valid range: A fully qualified class name
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

ssl.key.password

brokermediumdynamic3.94.14.2

The password of the private key in the key store file or the PEM key specified in 'ssl.keystore.key'.

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.keymanager.algorithm

brokermediumdynamic3.94.14.2

The algorithm used by key manager factory for SSL connections. Default value is the key manager factory algorithm configured for the Java Virtual Machine.

Default: SunX509
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

ssl.keystore.certificate.chain

brokermediumdynamic3.94.14.2

Certificate chain in the format specified by 'ssl.keystore.type'. Default SSL engine factory supports only PEM format with a list of X.509 certificates

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.keystore.key

brokermediumdynamic3.94.14.2

Private key in the format specified by 'ssl.keystore.type'. Default SSL engine factory supports only PEM format with PKCS#8 keys. If the key is encrypted, key password must be specified using 'ssl.key.password'

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.keystore.location

brokermediumdynamic3.94.14.2

The location of the key store file. This is optional for client and can be used for two-way authentication for client.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.keystore.password

brokermediumdynamic3.94.14.2

The store password for the key store file. This is optional for client and only needed if 'ssl.keystore.location' is configured. Key store password is not supported for PEM format.

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.keystore.type

brokermediumdynamic3.94.14.2

The file format of the key store file. This is optional for client. The values currently supported by the default `ssl.engine.factory.class` are [JKS, PKCS12, PEM].

Default: JKS
Valid range: Any valid string value
Scope: broker
Related configs: ssl.engine.factory.class

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.principal.mapping.rules

brokerlowstatic3.94.14.2

A list of rules for mapping from distinguished name from the client certificate to short name. The rules are evaluated in order and the first rule that matches a principal name is used to map it to a short name. Any later rules in the list are ignored. By default, distinguished name of the X.500 certificate will be the principal. For more details on the format please see security authorization and acls . Note that this configuration is ignored if an extension of KafkaPrincipalBuilder is provided by the `principal.builder.class` configuration.

Default: DEFAULT
Valid range: Any valid string value
Scope: broker
Related configs: principal.builder.class

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.protocol

brokermediumdynamic3.94.14.2

The SSL protocol used to generate the SSLContext. The default is 'TLSv1.3', which should be fine for most use cases. A typical alternative to the default is 'TLSv1.2'. Allowed values for this config are dependent on the JVM. Clients using the defaults for this config and 'ssl.enabled.protocols' will downgrade to 'TLSv1.2' if the server does not support 'TLSv1.3'. If this config is set to 'TLSv1.2', however, clients will not use 'TLSv1.3' even if it is one of the values in `ssl.enabled.protocols` and the server only supports 'TLSv1.3'.

Default: TLSv1.3
Valid range: Any valid string value
Scope: broker
Related configs: ssl.enabled.protocols

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.provider

brokermediumdynamic3.94.14.2

The name of the security provider used for SSL connections. Default value is the default security provider of the JVM.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

ssl.secure.random.implementation

brokerlowdynamic3.94.14.2

The SecureRandom PRNG implementation to use for SSL cryptography operations.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.trustmanager.algorithm

brokermediumdynamic3.94.14.2

The algorithm used by trust manager factory for SSL connections. Default value is the trust manager factory algorithm configured for the Java Virtual Machine.

Default: PKIX
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when the cluster is hitting concurrency or capacity limits. The use case is usually a busy broker that has enough hardware available but needs different worker-thread or connection limits to use it efficiently.

ssl.truststore.certificates

brokermediumdynamic3.94.14.2

Trusted certificates in the format specified by 'ssl.truststore.type'. Default SSL engine factory supports only PEM format with X.509 certificates.

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.truststore.location

brokermediumdynamic3.94.14.2

The location of the trust store file.

Default: null
Valid range: Any valid string value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.truststore.password

brokermediumdynamic3.94.14.2

The password for the trust store file. If a password is not set, trust store file configured will still be used, but integrity checking is disabled. Trust store password is not supported for PEM format.

Default: null
Valid range: Any valid password or secret value
Scope: broker
Related configs

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

ssl.truststore.type

brokermediumdynamic3.94.14.2

The file format of the trust store file. The values currently supported by the default `ssl.engine.factory.class` are [JKS, PKCS12, PEM].

Default: JKS
Valid range: Any valid string value
Scope: broker
Related configs: ssl.engine.factory.class

When you'd change it: Change this when you are setting up authentication, encryption, listener topology, or identity mapping. The use case is almost always environment-specific networking or security requirements rather than generic performance tuning.

telemetry.max.bytes

brokerlowstatic3.94.14.2

The maximum size (after compression if compression is used) of telemetry metrics pushed from a client to the broker. The default value is 1048576 (1 MB).

Default: 1048576 (1 mebibyte)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

transaction.abort.timed.out.transaction.cleanup.interval.ms

brokerlowstatic3.94.14.2

The interval at which to rollback transactions that have timed out

Default: 10000 (10 seconds)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

transaction.max.timeout.ms

brokerhighstatic3.94.14.2

The maximum allowed timeout for transactions. If a client’s requested transaction time exceed this, then the broker will return an error in InitProducerIdRequest. This prevents a client from too large of a timeout, which can stall consumers reading from topics included in the transaction.

Default: 900000 (15 minutes)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

transaction.partition.verification.enable

brokerlowdynamic3.94.14.2

Enable verification that checks that the partition has been added to the transaction before writing transactional records to the partition

Default: true
Valid range: true or false
Scope: broker
Related configs

When you'd change it: Change this when the use case requires duplicate protection or transactional guarantees across retries and restarts. These settings matter when correctness is more important than keeping the client configuration minimal.

transaction.remove.expired.transaction.cleanup.interval.ms

brokerlowstatic3.94.14.2

The interval at which to remove transactions that have expired due to `transactional.id.expiration.ms` passing

Default: 3600000 (1 hour)
Valid range: [1,...]
Scope: broker
Related configs: transactional.id.expiration.ms

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

transaction.state.log.load.buffer.size

brokerhighstatic3.94.14.2

Batch size for reading from the transaction log segments when loading producer ids and transactions into the cache (soft-limit, overridden if records are too large).

Default: 5242880
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are tuning the throughput versus latency trade-off. Increase or relax it when you want larger, more efficient batches; keep it tighter when low-latency delivery matters more than raw throughput.

transaction.state.log.min.isr

brokerhighstatic3.94.14.2

The minimum number of replicas that must acknowledge a write to transaction topic in order to be considered successful.

Default: 2
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the use case requires duplicate protection or transactional guarantees across retries and restarts. These settings matter when correctness is more important than keeping the client configuration minimal.

transaction.state.log.num.partitions

brokerhighstatic3.94.14.2

The number of partitions for the transaction topic (should not change after deployment).

Default: 50
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the use case requires duplicate protection or transactional guarantees across retries and restarts. These settings matter when correctness is more important than keeping the client configuration minimal.

transaction.state.log.replication.factor

brokerhighstatic3.94.14.2

The replication factor for the transaction topic (set higher to ensure availability). Internal topic creation will fail until the cluster size meets this replication factor requirement.

Default: 3
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

transaction.state.log.segment.bytes

brokerhighstatic3.94.14.2

The transaction topic segment bytes should be kept relatively small in order to facilitate faster log compaction and cache loads

Default: 104857600 (100 mebibytes)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when storage behavior needs to match the workload. Typical use cases are keeping a longer replay window, supporting slower consumers, shrinking disk usage, or making log cleanup and compaction happen more or less aggressively.

transaction.timeout.ms

clientlowdynamic3.94.14.2

The maximum amount of time in milliseconds that a transaction will remain open before the coordinator proactively aborts it. The start of the transaction is set at the time that the first partition is added to it. If this value is larger than the `transaction.max.timeout.ms` setting in the broker, the request will fail with a `InvalidTxnTimeoutException` error.

Default: 60000 (1 minute)
Valid range: Any valid integer unless constrained elsewhere
Scope: client
Related configs: transaction.max.timeout.ms

When you'd change it: Change this when you need to control how quickly clients or brokers give up, retry, or declare something unhealthy. The usual use case is a system with slower brokers, unstable networks, or consumer groups that need either faster detection or more tolerance.

transaction.two.phase.commit.enable

clientlowdynamic4.14.2

If set to true, then the broker is informed that the client is participating in two phase commit protocol and transactions that this client starts never expire.

Default: false
Valid range: true or false
Scope: client
Related configs

When you'd change it: Change this when the use case requires duplicate protection or transactional guarantees across retries and restarts. These settings matter when correctness is more important than keeping the client configuration minimal.

transactional.id

clientlowdynamic3.94.14.2

The TransactionalId to use for transactional delivery. This enables reliability semantics which span multiple producer sessions since it allows the client to guarantee that transactions using the same TransactionalId have been completed prior to starting any new transactions. If no TransactionalId is provided, then the producer is limited to idempotent delivery. If a TransactionalId is configured, `enable.idempotence` is implied. By default the TransactionId is not configured, which means transactions cannot be used. Note that, by default, transactions require a cluster of at least three brokers which is the recommended setting for production; for development you can change this, by adjusting broker setting `transaction.state.log.replication.factor`.

Default: null
Valid range: non-empty string
Scope: client
Related configs: enable.idempotence, transaction.state.log.replication.factor

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

transactional.id.expiration.ms

brokerhighstatic3.94.14.2

The time in ms that the transaction coordinator will wait without receiving any transaction status updates for the current transaction before expiring its transactional id. Transactional IDs will not expire while a the transaction is still ongoing.

Default: 604800000 (7 days)
Valid range: [1,...]
Scope: broker
Related configs

When you'd change it: Change this when the use case requires duplicate protection or transactional guarantees across retries and restarts. These settings matter when correctness is more important than keeping the client configuration minimal.

unclean.leader.election.enable

brokerhighdynamic3.94.14.2

Indicates whether to enable replicas not in the ISR set to be elected as leader as a last resort, even though doing so may result in data loss Note: In KRaft mode, when enabling this config dynamically, it needs to wait for the unclean leader election thread to trigger election periodically (default is 5 minutes). Please run `kafka-leader-election.sh` with `unclean` option to trigger the unclean leader election immediately if needed.

Default: false
Valid range: true or false
Scope: broker
Related configs: kafka-leader-election.sh

When you'd change it: Change this when you are deciding how much failure you can tolerate before writes fail or acknowledged data can be lost. These are the settings you touch when the use case is production durability rather than just getting the cluster to accept traffic.

value.deserializer

clienthighdynamic3.94.14.2

Deserializer class for value that implements the `org.apache.kafka.common.serialization.Deserializer` interface.

Default: Not specified
Valid range: A fully qualified class name
Scope: client
Related configs: org.apache.kafka.common.serialization.Deserializer

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

value.serializer

clienthighdynamic3.94.14.2

Serializer class for value that implements the `org.apache.kafka.common.serialization.Serializer` interface.

Default: Not specified
Valid range: A fully qualified class name
Scope: client
Related configs: org.apache.kafka.common.serialization.Serializer

When you'd change it: Change this when a producer or consumer needs to behave differently under real workload conditions. The use case is usually improving delivery guarantees, reducing latency, or making the client more predictable during failures.

Search Kafka configs without losing the operational context.

acks

add.partitions.to.txn.retry.backoff.max.ms

add.partitions.to.txn.retry.backoff.ms

advertised.listeners

allow.auto.create.topics

alter.config.policy.class.name

alter.log.dirs.replication.quota.window.num

alter.log.dirs.replication.quota.window.size.seconds

authorizer.class.name

auto.commit.interval.ms

auto.create.topics.enable

auto.leader.rebalance.enable

auto.offset.reset

background.threads

batch.size

bootstrap.servers

broker.heartbeat.interval.ms

broker.id

broker.rack

broker.session.timeout.ms

buffer.memory

check.crcs

cleanup.policy

client.dns.lookup

client.id

client.quota.callback.class

client.rack

compression.gzip.level

compression.lz4.level

compression.type

compression.zstd.level

config.providers

connection.failed.authentication.delay.ms

connections.max.idle.ms

connections.max.reauth.ms

controlled.shutdown.enable

controller.listener.names

controller.quorum.append.linger.ms

controller.quorum.auto.join.enable

controller.quorum.bootstrap.servers

controller.quorum.election.backoff.max.ms

controller.quorum.election.timeout.ms

controller.quorum.fetch.timeout.ms

controller.quorum.request.timeout.ms

controller.quorum.retry.backoff.ms

controller.quorum.voters

controller.quota.window.num

controller.quota.window.size.seconds

controller.socket.timeout.ms

create.topic.policy.class.name

default.api.timeout.ms

default.replication.factor

delegation.token.expiry.check.interval.ms

delegation.token.expiry.time.ms

delegation.token.max.lifetime.ms

delegation.token.secret.key

delete.records.purgatory.purge.interval.requests

delete.retention.ms

delete.topic.enable

delivery.timeout.ms

early.start.listeners

enable.auto.commit

enable.idempotence

enable.metrics.push

exclude.internal.topics

fetch.max.bytes

fetch.max.wait.ms

fetch.min.bytes

fetch.purgatory.purge.interval.requests

file.delete.delay.ms

flush.messages

flush.ms

follower.replication.throttled.replicas

group.consumer.assignors

group.consumer.heartbeat.interval.ms

group.consumer.max.heartbeat.interval.ms

group.consumer.max.session.timeout.ms

group.consumer.max.size

group.consumer.migration.policy