Introduction

In Kafka, linger.ms controls how long the producer is allowed to wait for additional records before sending a batch. Setting it to 0 tells the producer not to wait on purpose. That minimizes artificial batching delay, but it also means you usually send smaller batches, which can reduce throughput and compression efficiency.

What linger.ms Actually Changes

Kafka producers batch records per partition. A batch is sent when one of the usual triggers happens:

• the batch becomes full enough
• the producer decides it has waited long enough
• the sender thread is otherwise ready to flush work

linger.ms affects the second point. It does not mean every single send call becomes its own network packet. The producer can still batch naturally when records arrive quickly. But with linger.ms = 0, the producer does not intentionally wait to improve batch density.

Why Low Latency Can Cost Throughput

The main benefit of linger.ms = 0 is lower end-to-end latency under light or bursty traffic. If an application produces only a few records at a time and cares about shipping them immediately, waiting an extra few milliseconds may be undesirable.

The cost is that the producer often sends smaller batches. Smaller batches typically mean:

• more requests to brokers
• less effective compression
• more CPU spent per record on networking overhead
• lower throughput at higher message rates

That tradeoff matters most when the application produces many small messages.

A Minimal Producer Example

1import org.apache.kafka.clients.producer.KafkaProducer;
2import org.apache.kafka.clients.producer.ProducerConfig;
3import org.apache.kafka.clients.producer.ProducerRecord;
4import org.apache.kafka.clients.producer.RecordMetadata;
5
6import java.util.Properties;
7import java.util.concurrent.Future;
8
9public class Demo {
10    public static void main(String[] args) throws Exception {
11        Properties props = new Properties();
12        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
13        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
14        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
15        props.put(ProducerConfig.LINGER_MS_CONFIG, "0");
16        props.put(ProducerConfig.BATCH_SIZE_CONFIG, "16384");
17
18        try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
19            Future<RecordMetadata> result = producer.send(new ProducerRecord<>("events", "k1", "hello"));
20            System.out.println(result.get().offset());
21        }
22    }
23}

This configuration is valid, but it prioritizes low waiting time over deliberate batching.

When linger.ms = 0 Is a Good Fit

It is reasonable when the application values low per-record latency more than raw throughput. Examples include:

• request-response style event flows
• user-facing actions where a few milliseconds matter
• low-volume topics where batching gains are minimal anyway

If traffic is already sparse, adding linger may not buy much. There may simply not be enough nearby records to fill larger batches.

When It Becomes Expensive

At higher traffic levels, linger.ms = 0 often leaves performance on the table. If messages arrive continuously, even a tiny wait window can create fuller batches. Fuller batches help compression and reduce per-message overhead.

That is why tuning linger.ms is usually about system goals, not correctness. The producer still works with 0. The question is whether the latency gain justifies the efficiency loss.

batch.size and compression.type also matter. A larger batch size is only useful if records actually have time to accumulate, and compression benefits more when batches contain enough data.

Measure the Right Things

If you are deciding whether to keep linger.ms at 0, benchmark with realistic traffic and measure:

• producer-side latency
• broker request rate
• throughput in records or bytes per second
• compression ratio
• CPU usage on producers and brokers

A common mistake is measuring only one metric. A configuration can improve latency but degrade the total system cost badly under load.

Common Pitfalls

The most common mistake is assuming linger.ms = 0 disables batching completely. It does not. It only removes intentional waiting.

Another mistake is optimizing for the lowest possible latency in a workload where throughput and broker efficiency matter more.

A third issue is changing linger.ms without reconsidering batch.size, compression, and the actual traffic pattern.

Summary

• 'linger.ms = 0 means the producer does not intentionally wait to build fuller batches'
• It usually favors lower latency over maximum throughput
• Smaller batches can increase request overhead and reduce compression efficiency
• The setting is reasonable for latency-sensitive, low-volume publishing
• Benchmark with realistic traffic before deciding that 0 is the right long-term value