Kafka Interview Questions and Answers

Kafka interviews test whether you understand what happens to a message between the producer and the consumer. These questions cover the parts that come up most.

Q1BeginnerBasics

What are topics, partitions and offsets?

Short answer

A topic is a named stream of messages. It is split into partitions, each an ordered, append-only log stored on the brokers. An offset is a message's position within its partition, and consumers track how far they have read by offset.

Partitions are how Kafka scales: different partitions live on different brokers and are read in parallel by different consumers. Messages are kept for the configured retention period whether or not they have been read.

Common mistake

Saying Kafka guarantees ordering across a whole topic. Ordering is guaranteed only within a single partition.

Likely follow-ups

How do you choose the number of partitions?
What happens to messages after they are consumed?

Q2BeginnerConsumers

How do consumer groups work?

Short answer

Consumers that share a group id split a topic's partitions between them: each partition is read by exactly one consumer in the group at a time. A different group reads the same messages again, independently.

6 partitions and 3 consumers in a group: each consumer reads 2 partitions.
6 partitions and 8 consumers: 2 consumers sit idle - partitions, not consumers, limit parallelism.
A second group, for example analytics, receives every message too, with its own offsets.

Common mistake

Adding consumers beyond the number of partitions to go faster. The extra consumers get no partitions and do nothing.

Likely follow-ups

Where does Kafka store a group's committed offsets? (In the internal __consumer_offsets topic.)
What triggers a rebalance?

Q3IntermediateProducersOrdering

How do you keep related messages in order?

Short answer

Give them the same key. The default partitioner hashes the key, so every message with that key goes to the same partition - and within a partition, order is preserved.

OrderEvents.java · Java

// Every event for order 4521 lands on the same partition, in send order.
producer.send(new ProducerRecord<>("orders", "order-4521", "CREATED"));
producer.send(new ProducerRecord<>("orders", "order-4521", "PAID"));
producer.send(new ProducerRecord<>("orders", "order-4521", "SHIPPED"));

Messages with no key are spread across partitions, so they have no ordering relative to each other.

Common mistake

Increasing the partition count on a live topic without thinking. Keys then map to different partitions, so ordering for a key is broken across the change.

Likely follow-ups

What is a hot partition, and how do you avoid one?
How do retries affect ordering? (Use an idempotent producer.)

Q4AdvancedReliability

What delivery guarantees does Kafka offer, and how do you get exactly-once?

Short answer

At-most-once if you commit offsets before processing, at-least-once if you commit after - the usual choice. Exactly-once inside Kafka uses an idempotent producer plus transactions, with consumers reading only committed messages.

producer and consumer settings · Properties

# producer
enable.idempotence=true
acks=all
transactional.id=order-service-1

# consumer
isolation.level=read_committed
enable.auto.commit=false

Exactly-once covers reading from and writing to Kafka. Writing to an outside database still needs an idempotent consumer - for example, an upsert keyed on a message id - so a retry does no harm.

Common mistake

Claiming exactly-once delivery end to end with any external system, just by switching on idempotence.

Likely follow-ups

What does acks=all wait for?
Why is at-least-once with idempotent processing often enough?

Q5IntermediateReliabilityBrokers

How does replication work, and what is the ISR?

Short answer

Each partition has a leader and follower replicas on other brokers; the replication factor says how many copies exist. The ISR - in-sync replicas - are the followers fully caught up with the leader. If the leader fails, a new one is chosen from the ISR.

A common durable setup is replication factor 3, acks=all on the producer and min.insync.replicas=2 on the topic. A write then succeeds only once at least two copies have it, so losing one broker loses no acknowledged data.

Common mistake

Setting replication factor 3 but leaving acks=1. The producer then gets an acknowledgement as soon as the leader has the message, before any copy exists.

Likely follow-ups

What happens to writes when the ISR falls below min.insync.replicas?
What is unclean leader election, and why is it off by default?

Q6AdvancedConsumers

What is a consumer rebalance, and how do you reduce its impact?

Short answer

A rebalance reassigns partitions when consumers join, leave or are judged dead. With the classic eager protocol every consumer stops while it happens. Cooperative rebalancing moves only the partitions that need to move, and static membership stops a quick restart from triggering one at all.

consumer settings · Properties

partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor
group.instance.id=payments-consumer-1   # static membership
max.poll.interval.ms=300000             # time allowed between polls

A frequent cause of surprise rebalances is slow processing: if a consumer takes longer than max.poll.interval.ms between polls, it is removed from the group.

Common mistake

Doing slow work, such as a long external call per message, inside the poll loop without tuning max.poll.records or max.poll.interval.ms - which causes repeated rebalances.

Likely follow-ups

What is the difference between session.timeout.ms and max.poll.interval.ms?
How do you commit offsets safely during a rebalance?

Answers describe documented behaviour, checked against the sources listed. Platforms change between releases - confirm limits and versions before an interview.