Interview Questions
Kafka Interview Questions and Answers
Kafka questions test whether you understand partitioning and consumer groups well enough to reason about ordering guarantees and scaling -- the two things that trip up almost everyone new to it.
Example: A simple Kafka producer and consumer (Spring)
Java// Producer
@Service
public class OrderEventPublisher {
private final KafkaTemplate<String, String> kafkaTemplate;
public void publish(String orderId, String eventJson) {
// orderId as the key -- guarantees all events for the same order land in the same partition
kafkaTemplate.send("order-events", orderId, eventJson);
}
}
// Consumer
@KafkaListener(topics = "order-events", groupId = "inventory-service")
public void onOrderEvent(String eventJson) {
// process the event
}Frequently Asked Questions
A topic is split into partitions for parallelism -- each partition is an ordered, append-only log. Kafka only guarantees message order within a single partition, not across an entire topic. Records with the same key (like an order ID in the example above) always land in the same partition, which is how you guarantee all events for that order are processed in order.
A set of consumer instances that share the work of reading a topic -- Kafka assigns each partition to exactly one consumer within the group, so the group as a whole processes the full topic in parallel, with no two consumers in the same group reading the same partition. Different consumer groups are fully independent -- each group gets its own complete copy of the stream.
A per-partition, per-consumer-group pointer tracking how far that group has read. Kafka doesn't delete a message once it's read (unlike a traditional queue) -- the offset is just bookkeeping for where to resume. This is also how a consumer can "replay" a stream from an earlier point, or how a brand-new consumer group can read the entire history.
At-most-once (a message might be lost but is never processed twice), at-least-once (a message is never lost but might be processed more than once, e.g. after a consumer crash and restart before committing its offset), and exactly-once (available with Kafka's transactional/idempotent producer features, though it adds real complexity). Most real systems use at-least-once plus idempotent consumer logic, which is simpler to reason about than true exactly-once end-to-end.
You can increase partition count, but existing message-to-partition assignments for already-published data don't get rebalanced -- and more importantly, the same key can now hash to a different partition than before, which can break ordering guarantees for that key going forward. Partition count is usually planned upfront for exactly this reason.
Historically, Zookeeper managed cluster metadata -- which brokers are alive, topic/partition configuration, and leader election. Newer Kafka versions have moved to KRaft mode, where Kafka manages this metadata itself via a Raft consensus protocol, removing the separate Zookeeper dependency entirely -- worth knowing since it's an active area of change in the ecosystem.
Make your consumer's processing logic idempotent -- e.g. store a processed-message ID (or use the natural key of the operation, like an order ID) and check it before applying an update, so reprocessing the same message a second time is a safe no-op rather than a duplicate side effect (like charging a customer twice).