How do batching, linger and compression affect producer throughput and latency?

The producer does not send one record per request. It accumulates records per partition into batches in a buffer and a sender thread ships batches to brokers. Three settings shape this. batch.size is the maximum bytes per partition batch (default 16 KB). linger.ms is how long the producer waits for a batch to fill before sending it anyway. compression.type compresses a whole batch before it is sent. Bigger, fuller batches mean fewer requests, fewer round trips, less per-request overhead on the broker, and better compression ratios, because compression works across many similar records. That is why throughput rises. The cost is latency: with a non-zero linger, a record can wait up to linger.ms before leaving, and a bigger batch means more memory per partition.

The key insight is that these settings only matter if batches actually form. At low traffic, a batch never fills, so linger.ms is pure added latency. At high traffic, batches fill before linger expires and linger.ms barely matters. Spreading traffic across many partitions also hurts batching, because each partition has its own batch, which is why many partitions with low volume per partition produces tiny batches. For compression, lz4 and snappy are cheap on CPU, zstd gives better ratios at moderate CPU, and gzip is the slowest. Compressed batches stay compressed on the broker (when the topic compression.type is producer) and are decompressed only by consumers, so compression reduces network, disk and replication cost too.