Kafka Interview Questions Engineers Actually Get Asked

Interviewers rarely want a recited glossary. They want to hear that you have seen a broker die, a consumer group stall or a partition run hot, and that you know what Kafka does next. The questions below are written from first principles and the official Apache Kafka documentation, grouped the way interviews tend to run.

What core Kafka concepts should you know?

Start with short, accurate answers, then be ready to go one level deeper on behaviour. If you need a refresher, our guide to the key concepts of Apache Kafka and the Apache Kafka glossary cover the vocabulary.

• Topic: a named, append-only log of records that producers write to and consumers read from.
• Partition: the unit of parallelism and ordering. A topic is split into partitions, and each partition is an ordered sequence of records.
• Offset: a record’s position within a partition. Consumers track the offsets they have processed, and Kafka stores committed offsets in the internal __consumer_offsets topic.
• Broker: a server that stores partitions and serves producers and consumers.
• Consumer group: consumers that share the partitions of a topic, with each partition read by one member of the group at a time.
• Retention: records are deleted by time or size, whether or not they have been read.
• Log compaction: instead of deleting by age, Kafka keeps at least the latest record for each key.

The follow-up is usually “so what?”. For example: why does adding partitions change which partition a key lands on, and what does that do to ordering? Because the default partitioner hashes the key against the partition count, existing keys can move, so per-key ordering is only guaranteed within a stable partition count.

For certification-style preparation, our Confluent certified developer study guide is a useful companion.

What do interviewers ask about producers and consumers?

This is where candidates separate themselves, because the answers depend on configuration trade-offs rather than definitions.

What does acks control? It sets how many replicas must acknowledge a write before the producer treats it as successful.

What does an idempotent producer do? It stops retries creating duplicates within a partition. The broker tracks a producer ID and sequence numbers, so a retried batch is recognised and discarded. Idempotence has been the default since Kafka 3.0.

Does acks=all give you exactly-once? No, and this is a classic trap. acks=all is about durability. Exactly-once processing across read, process and write also needs the transactional producer and consumers reading with isolation.level=read_committed. Our notes on Kafka producer settings explain how these options fit together.

How should you commit offsets? Auto-commit is simple but can acknowledge records before your code has finished with them. Committing after processing gives at-least-once delivery, so your processing must tolerate duplicates. Committing before processing risks losing records on a crash.

What is a rebalance, and why does it hurt? When members join, leave or fail, partitions are reassigned. The classic protocol stops consumption while this happens. The newer consumer group protocol from KIP-848 is generally available in Kafka 4.0: brokers enable it after upgrade and clients opt in with group.protocol=consumer. It moves coordination to the broker and avoids most stop-the-world pauses.

How do you answer replication and failure questions?

Walk through a failure rather than drawing a diagram. Our Kafka replication explained article gives the background.

Each partition has one leader and zero or more followers. Producers and consumers talk to the leader, and followers copy from it. The in-sync replica set (ISR) is the leader plus the followers that are caught up.

Now take the standard question: what happens when a broker dies?

1. The controller notices the broker has gone.
2. For each partition that broker led, the controller elects a new leader from the ISR.
3. Clients refresh their metadata and carry on against the new leader.
4. When the broker returns, its replicas catch up and rejoin the ISR.

Two settings come up straight after. min.insync.replicas is the smallest ISR size at which acks=all writes are accepted. With replication factor 3 and min.insync.replicas=2, you can lose one broker and keep writing; lose two and producers get errors rather than silently weaker durability.

unclean.leader.election.enable decides whether an out-of-sync replica may become leader when the ISR is empty. Leaving it false (the default) favours consistency and may mean downtime. Turning it on favours availability and can lose acknowledged records. Explain which you would choose for payments and which for clickstream data.

Which KRaft and Kafka 4.0 questions come up?

Expect at least one. Kafka 4.0, released on 18 March 2025, runs in KRaft mode only; ZooKeeper mode was removed.

• Why was ZooKeeper removed? Running two systems meant two sets of operations, security and failure modes, and metadata propagation through ZooKeeper limited how far clusters could scale. KRaft keeps metadata inside Kafka itself. Our post on Kafka without ZooKeeper goes into the detail.
• What is the controller quorum? A group of controller nodes that use the Raft protocol to elect an active controller and replicate cluster metadata.
• Where is the metadata stored? In an internal log, the __cluster_metadata topic, which brokers and controllers replay to rebuild state quickly.
• How do you migrate? Clusters on ZooKeeper must move to KRaft before upgrading to 4.0, using the supported migration path through a Kafka 3.x release.

Do not memorise leaked exam answers. Interviewers can tell, and a short explanation of why the design changed is worth more.

What scenario questions should senior engineers expect?

Senior interviews swap definitions for incidents. A good structure is: diagnose, list options, state the trade-offs, then say how you would verify the fix.

• Consumer lag spike: check whether producers surged, consumers slowed or a rebalance loop started. Options include scaling consumers (up to the partition count), fixing slow processing or raising partitions. Verify with lag per partition, not total lag.
• Hot partition: usually a skewed key. Options are a better key, a custom partitioner or key salting, at the cost of weaker per-key ordering.
• Broker disk full: find which topics are growing, then adjust retention, add storage or move partitions. Verify that under-replicated partitions return to zero.
• Poison message: one record that always fails will block a partition. Use a dead-letter topic with bounded retries, and alert on it.
• Multi-region disaster recovery: compare active-passive and active-active replication, and be honest that offsets and ordering across clusters need planning.

If your team would rather not learn these lessons in production, our Kafka support and Kafka consulting services pages describe how we help.

Key takeaway: Strong Kafka answers explain behaviour under failure: what happens to data, ordering and consumers when a broker or client goes wrong.

Frequently asked questions