Sample questions
St Kafka Producer Consumer SemanticsDifficulty 2
In the Kafka producer, what does the linger.ms setting control?
- aHow long the producer waits to accumulate more records into a batch before sending it✓
- bHow long a broker keeps a message before it becomes eligible for deletion
- cHow long a consumer waits between
poll() calls before a rebalance - dHow long the producer waits for a broker acknowledgment before retrying
Explanation:linger.ms adds a small artificial delay before sending a batch, giving more records a chance to accumulate and improving throughput at the cost of latency. Waiting for an ack is governed by request.timeout.ms, poll cadence is a consumer concern, and message retention is a broker/topic setting.
St Kafka Producer Consumer SemanticsDifficulty 3
A producer has batch.size=16384 (bytes) and linger.ms=50. Under steady, moderate traffic, which condition actually triggers a batch to be sent to the broker?
- aBoth conditions must be true at the same time: the batch is full AND 50ms has elapsed
- bWhichever happens first: the batch fills to 16384 bytes, or 50ms elapses since the batch started✓
- cOnly
batch.size matters; linger.ms is ignored once a batch has any records in it - dOnly
linger.ms matters; batch.size only applies to the very first batch after startup
Explanation:The two settings are an OR condition, not an AND: a batch is sent as soon as either the size threshold is reached or the linger timer expires, whichever comes first. This lets a producer batch efficiently at high throughput while still bounding worst-case latency at low throughput.
St Kafka Producer Consumer SemanticsDifficulty 2
A producer's buffer.memory fills up because the broker is temporarily unreachable and unsent batches pile up. What happens to a new send() call in this situation?
- aIt immediately throws an exception with no waiting at all
- bIt automatically switches to writing the record straight to local disk instead
- cIt silently drops the record without notifying the application
- dIt blocks for up to
max.block.ms, then throws a timeout exception✓
Explanation:When the producer's memory buffer is full, send() blocks waiting for space (e.g. from a completed batch) for up to max.block.ms; if no space frees up in that window, it raises a timeout exception to the caller rather than silently dropping data.
St Kafka Producer Consumer SemanticsDifficulty 1
What does the producer's compression.type setting actually compress?
- aThe whole record batch, using a codec such as
gzip, snappy, lz4, or zstd✓ - bThe broker's on-disk log segments, applied after the batch is already written
- cThe TLS handshake payload between producer and broker
- dOnly the message key of each record, leaving the value uncompressed
Explanation:Compression in Kafka is applied at the batch level: the producer compresses the whole accumulated batch with the configured codec before sending, which is more efficient than compressing individual records.
St Kafka Producer Consumer SemanticsDifficulty 2
A producer repeatedly sends ProducerRecords with the same key, e.g. "user-42", to a topic that has 6 partitions and no manual partition override. What happens to these records?
- aThey are routed to whichever partition currently has the least data
- bThey land on partition 0, regardless of the key's value
- cThey are spread round-robin across all 6 partitions to balance load evenly
- dThey are all hashed to the same partition, as long as the partition count stays at 6✓
Explanation:The default partitioner hashes the record key to deterministically pick a partition, so the same key always maps to the same partition as long as the partition count is unchanged. This is what makes per-key ordering possible.
St Kafka Producer Consumer SemanticsDifficulty 3
A producer sends records with no key (key == null) to a topic. In modern Kafka clients (2.4+), how does the default partitioner distribute these records across partitions?
- aIt sends every consecutive record to a strictly different partition in round-robin order
- bIt sticks to one partition, filling a batch there before switching to another partition✓
- cIt sends all keyless records to partition 0 only, to keep ordering simple
- dIt refuses to send keyless records unless a custom partitioner is configured
Explanation:Kafka's default logic has used sticky batching for keyless records since 2.4: it stays on a partition until a batch is ready, then switches. Kafka 3.3 changed the implementation through KIP-794 but retained this batching behavior while adding adaptive broker-performance awareness.