The configuration fetch.max.wait.ms specifies how long to wait if the minimum number of bytes to fetch specified by the previous configuration fetch.min.bytes aren’t available.

max.partition.fetch.bytes

The configuration max.partition.fetch.bytes specifies the maximum number of bytes returned by a broker per partition. Obviously, this value has to be higher than the largest message the broker will accept, otherwise the consumer can hang trying to read a message that is greater than max.partition.fetch.bytes but within acceptable limits for the broker. Setting too high a value may return more records than the consumer can process in a timely manner. This can be a problem as the poll() call is also responsible for sending out heartbeats, and thus a delay in the next invocation of poll() may result in a session timeout followed by a rebalance (covered later). This situation can be mitigated by either choosing a lower value for this configuration or setting a high enough value for session timeout.

By default, max.partition.fetch.bytes is set to 1MB. If we have 20 partitions and 4 consumers then each consumer will read from 5 partitions. This implies that each consumer must have at least 5MB of available memory for ConsumerRecords. In reality, more memory per consumer will be needed as other consumers in the group can fail. This triggers a rebalance and causes the remaining consumers to divide up the load for the failed consumer amongst themselves.