Apache Kafka Interview Questions: Practical and Conceptual

Kafka interviews reward people who understand why the system behaves as it does. Almost every hard question comes back to four ideas: partitions, offsets, replication and delivery guarantees. Get those right and the follow-ups become reasoning exercises rather than memory tests.

Below are the questions that come up most, answered the way an interviewer hopes to hear them. Each is marked by level. If you are a fresher, aim to answer every Core question in your own words. If you are experienced, expect the Advanced questions and a design exercise like the one near the end.

The core model

What is Kafka, in one or two sentences? (Core)

An event streaming platform in which producers write events to topics and consumers read them, with the two sides fully decoupled. Producers never wait for consumers. Unlike traditional messaging systems, events are not deleted when they are read. Each topic keeps them for a configured retention period, so many consumers can read the same data, as often as they need.

What is a partition, and why does it matter? (Core)

A topic is split into partitions spread across brokers, which lets clients read and write through many brokers at once. Each new event is appended to one partition. Events with the same key, such as a customer ID, go to the same partition, and Kafka guarantees that a consumer reads a partition’s events in the order they were written.

The phrase interviewers listen for: ordering is per partition, not per topic. If you need all events for one customer in order, key by customer ID.

What is an offset? (Core)

The position of a record in a partition. A consumer’s progress in a partition is a single integer, the offset of the next message it will read. That is why tracking progress is cheap, and why a consumer can deliberately rewind and reprocess data, for example after fixing a bug.

Push or pull: how do consumers get data? (Core)

Consumers pull. They send fetch requests to the partition leaders with the offset they want. The design documentation explains the choice: in a push system a slow consumer can be overwhelmed, whereas with pull it simply falls behind and catches up. To avoid busy-waiting when there is no data, a fetch can “long poll” until data arrives.

How does a producer choose a partition? (Core)

The producer sends directly to the partition leader. It can spread records without a key, or use a key that is hashed to a partition, and you can plug in a custom partitioner. Producers also batch records in memory and send them together, trading a little latency for throughput.

Consumer groups

How do consumer groups scale reading? (Core)

Within a consumer group, each partition is consumed by exactly one consumer at a time. Add consumers and partitions are spread across them. Different groups read the same topic independently, each with its own offsets.

A topic has 6 partitions. What happens with 8 consumers in one group? (Core)

Two consumers get no partitions and sit idle, because a partition is never shared within a group. The partition count therefore caps the parallelism of a single group. This is one of the most common fresher questions, and a good follow-up from you is that increasing partitions later changes which partition a given key maps to, which can break per-key ordering assumptions.

What is a rebalance, and why do people dislike them? (Advanced)

When members join or leave, partitions are reassigned. With dynamic membership, routine restarts or deployments can trigger reassignment of many partitions, and stateful applications may take a long time to rebuild local state. Two answers show depth:

• Static membership: each consumer sets a persistent group.instance.id, so a restart with the same ID does not trigger a rebalance.
• The new consumer group protocol (KIP-848): generally available in Kafka 4.0 and designed to reduce “stop-the-world” rebalances. It is enabled on the broker side by default, but consumers must opt in with group.protocol=consumer.

What are share groups? (Advanced)

A newer, queue-like way to consume. In a share group, partitions can be assigned to several consumers, the number of consumers can exceed the number of partitions, records are acknowledged individually, and delivery attempts are counted so unprocessable records can be handled automatically. A fetched record is locked for that consumer, by default for 30 seconds (share.record.lock.duration.ms). The feature arrived as early access in Kafka 4.0, and the Kafka 4.2.0 release announcement (February 2026) describes share groups as production-ready. Check which version your target employer runs before claiming production experience with it.

Replication and durability

Explain leaders, followers and the ISR. (Core)

Each partition has one leader and zero or more followers. Writes go to the leader. Followers copy the leader’s log the same way a consumer would. The leader tracks the in-sync replicas (ISR): replicas that have an active session with the controller and have not fallen too far behind, as set by replica.lag.time.max.ms. A message counts as committed once all replicas in the ISR have it, and consumers only ever see committed messages.

What do acks=0, acks=1 and acks=all mean? (Core)

• acks=0: the producer does not wait for acknowledgement.
• acks=1: the leader has written it; followers may not have it yet.
• acks=all (also -1): all current in-sync replicas have it.

The catch is the word “current”. With two replicas and one down, the ISR is just the leader, so acks=all writes still succeed and could be lost if that broker also fails. That is why min.insync.replicas exists. It only takes effect with acks=all, and if the ISR drops below the minimum, the partition rejects writes rather than risk losing them.

How would you configure a topic so you do not lose data? (Advanced)

A typical answer is replication factor 3, which the introduction describes as a common production setting, min.insync.replicas=2, producers on acks=all, and unclean leader election disabled. Then state the cost: if two of the three replicas are unavailable, writes stop. Durability is bought with availability, and a strong candidate says so without being asked.

What is unclean leader election? (Advanced)

If every in-sync replica is down, Kafka can either wait for one to return, or promote the first replica that comes back even if it is missing committed messages. Waiting is the default (since 0.11.0.0). Allowing unclean election through unclean.leader.election.enable favours uptime over consistency.

Delivery semantics

At-most-once, at-least-once, exactly-once: what does Kafka give you by default? (Core)

At-least-once. The consumer side decides a lot: if you commit the offset before processing and then crash, you get at-most-once. If you process first and commit afterwards, a crash between the two means some messages are processed twice, which is at-least-once. Duplicates are harmless when processing is idempotent, for example an upsert by primary key.

What does the idempotent producer do? (Advanced)

Without it, a producer that gets a network error cannot tell whether the write succeeded, so it retries and may create duplicates. Since 0.11.0.0, the broker gives each producer an ID and uses a sequence number on every message to discard duplicates caused by retries.

So is exactly-once real? (Advanced)

Within Kafka, yes, in a specific sense. When an application reads from Kafka and writes back to Kafka, the transactional producer can write the output and the consumer’s offsets in one transaction. Downstream consumers using read_committed isolation see only committed transactions. The default, read_uncommitted, also shows messages from aborted transactions. Kafka Streams uses this to offer exactly-once processing.

The limit is the edge of Kafka. Writing to an external database exactly once needs that system’s cooperation, typically by storing offsets alongside the output so both update or neither does. Interviewers often ask this precisely to see whether you will over-claim.

Storage and operations

What is log compaction, and when would you use it? (Advanced)

Instead of deleting by age, a compacted topic keeps at least the latest record for each key. That suits changelogs and “current state” data, such as a user’s latest profile. Key points:

• A record with a key and a null value is a tombstone and deletes that key.
• Tombstones are kept for delete.retention.ms (default 24 hours), so a consumer lagging longer than that can miss a delete.
• Compaction never reorders messages, and offsets never change.

What changed in Kafka 4.0? (Core for anyone claiming recent experience)

Kafka 4.0 is the first major release that runs entirely without Apache ZooKeeper. KRaft mode is the default, so there is no separate ZooKeeper ensemble to operate. The release also made the new consumer rebalance protocol generally available and raised Java requirements: Java 11 for clients and Kafka Streams, Java 17 for brokers, Connect and tools. If your experience is on older ZooKeeper-based clusters, say so and show you understand what moved, rather than glossing over it.

How does Kafka decide a broker is alive? (Advanced)

In KRaft clusters, brokers send heartbeats to the controller. If none arrives before broker.session.timeout.ms expires, the broker is considered offline and removed from the ISR. A follower that has a session but lags too far behind can also be removed by the leader.

A design question, worked through

Illustrative prompt: “Design the event pipeline for an online shop’s orders. Each order’s events (created, paid, shipped) must be processed in order, nothing may be lost, and the stock service must not double-count.”

1. Topic and key. One orders topic keyed by order ID, so each order’s events stay in one partition and in sequence.
2. Partition count. Size for the consumer parallelism you expect at peak, with headroom, because adding partitions later remaps keys.
3. Durability. Replication factor 3, min.insync.replicas=2, acks=all, idempotent producer.
4. Consumption. The stock service commits offsets only after processing, accepting at-least-once delivery.
5. No double-counting. Make the stock update idempotent, for example by recording processed event IDs in the same database transaction as the stock change.
6. Failure cases. Explain what happens if a broker dies (leader moves to an in-sync follower), if a consumer dies (its partitions are reassigned), and if a record cannot be processed (park it in a separate topic for investigation rather than blocking the partition).

You will not be marked on matching a model answer. You will be marked on whether each choice has a reason and a stated cost.

Questions that catch people out

• “Kafka guarantees ordering.” Only within a partition.
• “acks=all means every replica has it.” Only every replica currently in sync.
• “Reading a message removes it.” No. Retention, not consumption, removes data.
• “More consumers always means faster.” Not beyond the partition count in a consumer group.
• “Exactly-once works end to end.” Within Kafka, with transactions. External systems need their own approach.

Preparing for the interview

Run a local single-node cluster and do three experiments: produce keyed messages and confirm which partition each lands in; start more consumers than partitions and watch which ones sit idle; stop a consumer mid-stream and see where it resumes. Ten minutes of each gives you real observations to talk about, which interviewers value more than definitions.

On your CV, quantify what you ran: number of topics or partitions, throughput, the incident you resolved, the latency you cut. The software engineer resume builder and the data analyst resume builder both have room for that kind of project detail.

Frequently asked questions

Do I need to know Java for a Kafka interview?

Not always. Many roles use Kafka from Python, Go or other clients, but the official clients and Kafka Streams are Java-based, so platform and streaming roles often expect some familiarity.

Which Kafka version should I prepare for?

Know the 4.x changes (no ZooKeeper, KRaft by default, the new consumer protocol, production-ready share groups from 4.2), but ask the employer what they run. Many companies still operate older clusters or managed services with their own limits.

How many partitions should a topic have?

There is no universal number. Explain the factors instead: target consumer parallelism, throughput per partition, key distribution, and the fact that increasing partitions later changes key-to-partition mapping.

What is the best way to answer a question I do not know?

Reason from the four basics. “I have not used that setting, but given that ordering is per partition and the ISR defines committed data, I would expect…” is a far better answer than a guess.

Sources

• Introduction (Getting started), Apache Kafka documentation (source on GitHub)
• Design, Apache Kafka documentation (source on GitHub)
• Apache Kafka 4.0.0 Release Announcement, The Apache Software Foundation
• Apache Kafka 4.2.0 Release Announcement, The Apache Software Foundation