Kafka Interview Questions for Java Backend Developers (2026): Partitions, Offsets and Delivery Guarantees
By Preeti Verma
Apache Kafka has become a standard part of backend and microservices interviews. You do not need to be a Kafka administrator to answer well. You do need to explain the core ideas clearly and reason about what happens when something fails.
This guide covers the questions that come up most for Java backend roles, with the points a strong answer makes.
1. What is Kafka, and when would you use it?
Kafka is a distributed, durable, append-only log. Producers write messages to it, and consumers read them at their own pace. Typical uses: decoupling services, event streaming, activity tracking, feeding analytics pipelines, and absorbing traffic spikes so a slow consumer does not slow the producer.
Say how it differs from a traditional queue: messages are not deleted when read. They stay for a configured retention period, so several consumer groups can each read the same data independently, and a new consumer can replay old messages.
2. Explain topics, partitions and offsets
A topic is a named stream of messages. It is split into partitions, and each partition is an ordered, append-only sequence. Every message in a partition has an offset, its position in that sequence.
The key interview point: ordering is guaranteed only within a partition, not across the whole topic. If order matters for something (all events for one order, one user, one account), send them with the same key so they land in the same partition.
3. How does a producer choose a partition?
If you give a message a key, the producer hashes the key and the same key always goes to the same partition (while the partition count stays the same). With no key, messages are spread across partitions. A thoughtful addition: a badly chosen key can cause a hot partition, where one very active key gets all the traffic while other partitions sit idle.
4. What is a consumer group?
A consumer group is a set of consumers that share the work of reading a topic. Kafka assigns each partition to exactly one consumer in the group at a time. So:
- More consumers than partitions means some consumers sit idle.
- To scale a group, you need enough partitions.
- Two different groups each get every message.
This is the answer to "how do you scale consumption?": add consumers up to the partition count, and plan the partition count ahead of time.
5. What are offsets, commits and how can messages be lost or duplicated?
A consumer tracks the offset it has processed and commits it back to Kafka. When to commit decides the guarantee:
- Commit before processing: if it crashes mid-way, the message is skipped (at most once).
- Commit after processing: if it crashes after processing but before committing, the message is processed again on restart (at least once).
Most systems choose at least once and make the consumer idempotent, meaning that handling the same message twice has the same effect as once, for example by checking a unique message id before writing.
6. Explain delivery semantics, including exactly-once
- At most once: no duplicates, possible loss.
- At least once: no loss, possible duplicates.
- Exactly once: each message affects the result once.
Kafka supports exactly-once processing within Kafka through an idempotent producer and transactions. Be honest about the limit: once your consumer writes to an external system such as a database, exactly-once depends on that write being idempotent or being part of the same transactional design. Saying this clearly impresses interviewers more than claiming Kafka magically gives exactly-once everywhere.
7. What do acks and replication mean for durability?
Each partition has replicas on different brokers, with one leader handling reads and writes. The producer setting acks controls when a write counts as successful:
acks=0: do not wait. Fastest, can lose data.acks=1: the leader has written it.acks=all: all in-sync replicas have written it. Safest.
Pair acks=all with min.insync.replicas (for example 2 with replication factor 3), so a write fails rather than being accepted by a single broker that could then fail. The trade-off is a little more latency for much stronger durability.
8. What is a consumer rebalance, and why is it a problem?
When consumers join or leave a group, or partitions change, Kafka reassigns partitions. During a rebalance, consumption can pause. Frequent rebalances are a sign of something wrong, often consumers that take too long to process a batch and miss their heartbeat or poll deadline. Fixes: process faster, reduce the batch size (max.poll.records), or tune the poll and session timeouts. Mention static group membership or cooperative rebalancing as newer improvements if you know them.
9. How do you handle a message that keeps failing?
Do not retry forever on the same partition, because one bad message can block everything behind it. A common design:
- Retry a few times with backoff (separate retry topics if you need delays).
- If it still fails, publish it to a dead-letter topic with the error details.
- Alert and have a way to inspect and replay it.
Distinguish transient failures (a downstream service is briefly down, retry makes sense) from permanent ones (invalid data, retrying never helps).
10. What is consumer lag, and how do you act on it?
Lag is how far a consumer group is behind the latest offset. Growing lag means consumers cannot keep up. Check processing time per message, scale out up to the partition count, look for a slow dependency, and make sure a single slow message is not blocking a partition. Say that you would alert on lag, not just on errors.
11. What is log compaction?
For a compacted topic, Kafka keeps at least the latest message for each key and removes older ones, instead of deleting by age. It suits "current state" data such as the latest profile per user, and for rebuilding state from the log.
12. Kafka vs RabbitMQ (and other message queues)
A fair comparison: RabbitMQ is a broker built around queues and flexible routing, where messages are typically removed once consumed. Kafka is a distributed log built for very high throughput, replay and many independent consumers. Neither is "better". Match the tool to the need: task queues and complex routing often suit RabbitMQ, while event streaming and replay suit Kafka.
13. How do you use Kafka in Spring Boot?
Mention spring-kafka, KafkaTemplate for producing, and @KafkaListener for consuming. Be ready to talk about serializers (JSON or Avro with a schema registry), error handlers with back-off and dead-letter publishing, and setting a consumer group id. Add that you would use a schema registry or a versioning strategy so changing a message format does not break consumers.
Scenario questions
- "Orders for the same customer must be processed in order. How do you design the topic?" (Key by customer id, so they share a partition.)
- "Your consumer processed a payment event twice. What went wrong and how do you prevent it?" (At-least-once delivery, make the handler idempotent.)
- "Consumer lag is growing. Walk me through what you check."
- "One poison message blocks the partition. What do you do?" (Retry limits, dead-letter topic.)
How to practise
Run Kafka locally with Docker, write a producer and a consumer, then kill the consumer mid-way and see what happens to offsets. Seeing duplicates yourself makes idempotency click. Then explain the design out loud, as in a system design interview, and test yourself with our microservices interview questions for Java developers or a mock interview.
FAQ
Do I need to know Kafka internals for a Java developer role? For most roles, the concepts above are enough. Broker internals such as the controller, ISR mechanics and segment files are usually asked only for senior or platform roles.
Is Kafka asked if my resume does not mention it? Often it is asked in microservices and system design rounds anyway, so know the basics.
The takeaway
Explain Kafka with partitions, consumer groups and offsets, be clear that ordering is per partition, and show that you design consumers to be idempotent and to handle failures. Those three things cover most of what interviewers want to hear.