Kafka Interview Questions (2026)
Practice 45 Kafka interview questions on topics, partitions, brokers, producers, consumers, consumer groups, offsets, retention, compaction, and delivery guarantees.
45 questions with answersWhat Is Apache Kafka?
Key Takeaways
- ✓Apache Kafka is a distributed event streaming platform used to publish, store, and consume event records at scale.
- ✓Core interview topics include topics, partitions, brokers, replicas, producers, consumers, offsets, consumer groups, and retention.
- ✓Strong answers explain ordering, replay, backpressure, partition keys, delivery guarantees, and failure handling.
- ✓Kafka is not a normal queue. It stores an ordered log per partition and consumers track their own position.
Apache Kafka is a distributed event streaming platform for durable event logs, real-time pipelines, and asynchronous system communication. Producers write records to topic partitions, brokers store replicated logs, and consumers read records by offset. In interviews, Kafka questions test whether you understand ordering, replay, consumer groups, partitioning, retention, compaction, and operational failure modes.
Watch: Introduction to Apache Kafka Fundamentals
Video: Introduction to Apache Kafka Fundamentals (Confluent, YouTube)
Test yourself and earn a certificate
6 quick questions. Score 70%+ to download your Kafka certificate.
All Questions on This Page
45 questions- 1. What is a Kafka topic?
- 2. Why does Kafka use partitions?
- 3. What is a Kafka broker?
- 4. Why does Kafka replicate partitions?
- 5. What does a partition leader do?
- 6. What does a Kafka producer do?
- 7. What does a Kafka consumer do?
- 8. What is a consumer group?
- 9. What is an offset?
- 10. What is Kafka retention?
- 11. What is log compaction?
- 12. What does acks control?
- 13. What is an idempotent producer?
- 14. What is consumer lag?
- 15. What is a dead-letter topic?
- 16. How do you choose a Kafka partition key?
- 17. Design an orders event topic.
- 18. How do you handle duplicate Kafka messages?
- 19. When should a consumer commit offsets?
- 20. How do you monitor Kafka lag?
- 21. How do you reduce consumer lag?
- 22. How do you design retries?
- 23. How do you handle event schema changes?
- 24. How do you set topic retention?
- 25. When would you use a compacted topic?
- 26. How do you configure a reliable producer?
- 27. What happens during a rebalance?
- 28. How do you guarantee order for a user's events?
- 29. How do you secure Kafka?
- 30. How do you plan Kafka capacity?
- 31. One Kafka partition receives most traffic. What is wrong?
- 32. A consumer group stops making progress. What do you check?
- 33. A payment consumer processes the same event twice. What should have protected it?
- 34. Messages appear missing after a producer failure. What do you inspect?
- 35. Lag spikes after a consumer deploy. What is likely?
- 36. A consumer was down longer than retention. What happens?
- 37. A producer removes a field and consumers fail. What prevents this?
- 38. Consumers keep rebalancing. What do you inspect?
- 39. Can a topic have too many partitions?
- 40. A compacted topic lost older values. Is that expected?
- 41. A team wants total ordering across millions of events. What do you say?
- 42. A broker fails. Why can Kafka keep running?
- 43. A database sink slows down Kafka consumers. What helps?
- 44. An event contains only changed fields and consumers break. What is the issue?
- 45. What would you ask before approving a Kafka design?
Kafka Fundamentals
Foundational15 questionsStart here. These are the definitions and first-principle checks that open most rounds.
Q1. What is a Kafka topic?
A topic is a named stream of records split into partitions.
Producers write to topics and consumers read from them.
Topic changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Introduction to Apache Kafka Fundamentals (Confluent, YouTube)
Q2. Why does Kafka use partitions?
Partitions divide a topic for parallelism, ordered logs, and scalable storage.
Ordering is guaranteed only within one partition.
Partition changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Kafka record path
The key controls partition placement when configured.
Q3. What is a Kafka broker?
A broker is a Kafka server that stores partitions and handles producer and consumer requests.
A cluster has multiple brokers for scale and fault tolerance.
Broker changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q4. Why does Kafka replicate partitions?
Replication keeps partition data available if a broker fails.
Each partition has a leader and follower replicas.
Replica changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
| Answer part | What to say | Evidence to mention |
|---|---|---|
| Definition | Replica in one direct sentence. | Official docs or course material |
| Use case | The work where it changes a decision. | Dataset, model, query, dashboard, or pipeline |
| Risk | What breaks when it is misunderstood. | Metric, log, test result, or review note |
Q5. What does a partition leader do?
The leader handles reads and writes for a partition while followers replicate from it.
Leader election happens when the leader broker fails.
Leader changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Kafka tutorial for beginners (Confluent Developer, YouTube)
Q6. What does a Kafka producer do?
A producer sends records to Kafka topics and chooses partitions by key, custom logic, or default strategy.
Producer settings affect reliability, latency, and throughput.
Producer changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q7. What does a Kafka consumer do?
A consumer reads records from topic partitions and tracks progress with offsets.
Consumers can replay by seeking to earlier offsets if retention allows it.
Consumer changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q8. What is a consumer group?
A consumer group lets multiple consumers share partitions from a topic so records are processed in parallel.
Within one group, one partition is consumed by one consumer at a time.
Consumer group changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q9. What is an offset?
An offset is a record's position inside a partition log.
Committed offsets mark how far a consumer group has processed.
Offset changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q10. What is Kafka retention?
Retention controls how long records stay in Kafka based on time, size, or policy.
Records can remain after being consumed.
Retention changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q11. What is log compaction?
Log compaction keeps the latest value for each key while removing older values for that key over time.
It is useful for state topics.
Compaction changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q12. What does acks control?
acks controls how many broker confirmations the producer waits for before considering a write successful.
acks=all gives stronger durability with higher latency.
Acknowledgment changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q13. What is an idempotent producer?
An idempotent producer prevents duplicate records caused by producer retries within a session.
It helps make retries safer.
Idempotent producer changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: The Confluent Platform (Confluent, YouTube)
Q14. What is consumer lag?
Consumer lag is the difference between the latest offset and the consumer group's committed or processed offset.
Lag shows how far the consumer is behind.
Consumer lag changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q15. What is a dead-letter topic?
A dead-letter topic stores records that could not be processed after validation or retry rules.
It keeps bad records visible without blocking the whole stream.
Dead-letter topic changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Kafka Practical Interview Questions
Intermediate15 questionsThese questions test whether you can apply the topic to real data, real code, and messy constraints.
Q16. How do you choose a Kafka partition key?
Choose a key that preserves needed ordering and spreads load evenly across partitions.
A user id may work for user-ordering, but a hot user can create skew.
choose partition key changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
# Interview check: split data, run baseline, inspect metric
from sklearn.metrics import accuracy_score
print(accuracy_score(y_true, y_pred))Q17. Design an orders event topic.
Define event names, key, schema, partition count, retention, compatibility, and consumers.
The key decision is whether the topic represents facts, commands, or state changes.
design event topic changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q18. How do you handle duplicate Kafka messages?
Make consumers idempotent using event ids, unique keys, processed tables, or safe merge logic.
At-least-once processing can create duplicates.
handle duplicates changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q19. When should a consumer commit offsets?
Commit after the record or batch is processed successfully according to the sink's consistency rule.
Committing too early risks data loss after failure.
commit offsets changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q20. How do you monitor Kafka lag?
Track consumer group lag, processing rate, input rate, rebalance events, and sink latency.
Lag needs context. A short spike may be normal.
measure lag changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q21. How do you reduce consumer lag?
Scale consumers up to partition count, improve processing, batch writes, fix slow sinks, or increase partitions if design allows.
More consumers than partitions in one group do not add parallelism.
fix lag changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q22. How do you design retries?
Use bounded retries, delay topics where fit, idempotent processing, and a dead-letter topic after final failure.
Retry loops should not block good records forever.
retry failed records changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q23. How do you handle event schema changes?
Use a schema registry or contract, compatibility rules, optional additive fields, and versioned consumers.
Breaking changes need coordinated rollout.
schema evolution changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q24. How do you set topic retention?
Base it on replay need, storage cost, legal rules, and consumer recovery time.
Short retention can make slow consumers unrecoverable.
topic retention changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q25. When would you use a compacted topic?
Use compaction when consumers need the latest state per key, such as account status or reference data.
Do not use compaction for audit history that needs every event.
compacted topic changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Watch a deeper explanation
Video: Confluent offerings and Kafka 101 (Confluent, YouTube)
Q26. How do you configure a reliable producer?
Use acks=all, retries, idempotence, sensible timeout settings, and monitoring for errors.
Reliability settings may increase latency.
producer reliability changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q27. What happens during a rebalance?
Partitions are reassigned among consumers in a group, which can pause processing and change ownership.
Long processing can trigger unnecessary rebalances.
consumer rebalance changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q28. How do you guarantee order for a user's events?
Use the same partition key for that user's events and process them within one partition.
Global ordering across partitions is not guaranteed.
order guarantee changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q29. How do you secure Kafka?
Use TLS, authentication, ACLs, network controls, audit logging, and secret management.
Security includes brokers, clients, schemas, and operational access.
secure Kafka changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q30. How do you plan Kafka capacity?
Estimate message size, throughput, retention, replication factor, partitions, consumer rate, and broker disk/network headroom.
Retention and replication multiply storage.
capacity planning changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Kafka Advanced Scenarios
Advanced15 questionsAdvanced rounds test trade-offs, failure modes, and whether the decision can hold up under production pressure.
Q31. One Kafka partition receives most traffic. What is wrong?
The partition key is skewed or too many records share the same key.
Change key strategy carefully because ordering may change.
hot partition changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q32. A consumer group stops making progress. What do you check?
Check lag, errors, rebalances, offsets, dead records, sink latency, and consumer logs.
A poison message can block a naive consumer.
consumer stuck changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q33. A payment consumer processes the same event twice. What should have protected it?
Idempotency at the consumer or sink should prevent duplicate business effects.
Kafka delivery settings alone do not replace business idempotency.
duplicate payments changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q34. Messages appear missing after a producer failure. What do you inspect?
Check acks, retries, idempotence, producer errors, broker availability, and topic retention.
A producer can lose data if it treats unconfirmed writes as successful.
lost messages changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q35. Lag spikes after a consumer deploy. What is likely?
A slower code path, sink issue, rebalance loop, bad batch size, or errors may have reduced processing rate.
Compare input and processing rate before and after deploy.
lag after deploy changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q36. A consumer was down longer than retention. What happens?
Offsets may point to records that no longer exist, so the group cannot replay all missed data.
Recovery may require source replay or backup.
short retention incident changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q37. A producer removes a field and consumers fail. What prevents this?
Compatibility checks, schema registry rules, and producer-consumer contracts.
Removing required fields is usually a breaking change.
schema break changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q38. Consumers keep rebalancing. What do you inspect?
Check session timeouts, max poll interval, slow processing, consumer crashes, and group membership changes.
Frequent rebalances reduce throughput.
rebalance storm changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q39. Can a topic have too many partitions?
Yes. Too many partitions increase metadata, open files, leader election work, and operational overhead.
Partitions are not free.
too many partitions changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q40. A compacted topic lost older values. Is that expected?
Yes, compaction keeps latest values by key over time and can remove older records.
Use normal retention if every event must be preserved.
compaction confusion changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q41. A team wants total ordering across millions of events. What do you say?
Kafka orders within a partition. Total ordering would require one partition or an external ordering design, which limits scale.
Challenge whether total ordering is truly needed.
cross-partition order changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q42. A broker fails. Why can Kafka keep running?
Replicated partitions can elect new leaders if enough in-sync replicas remain.
Replication factor and min in-sync replicas matter.
broker failure changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q43. A database sink slows down Kafka consumers. What helps?
Batch writes, tune the database, add backpressure, scale partitions and consumers if possible, or buffer to a more suitable sink.
Kafka can absorb spikes only within retention and capacity.
slow sink changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q44. An event contains only changed fields and consumers break. What is the issue?
Consumers may not have enough context unless the event contract defines patch semantics clearly.
State events and fact events need different contracts.
bad event design changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Q45. What would you ask before approving a Kafka design?
Ask about key choice, ordering, retention, schemas, consumer groups, retries, idempotency, security, lag alerts, and replay plan.
These questions expose real production risk.
senior design review changes Kafka decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.
Kafka vs Queue vs Database Table
Kafka is often compared with queues and database tables. The useful answer is about retention, replay, ordering, and consumer ownership.
| System | Data model | Good fit | Interview trap |
|---|---|---|---|
| Kafka | Append-only partitioned log | Event streams, replay, fan-out | Assuming one message disappears after one consumer |
| Queue | Work item queue | Task distribution | Expecting easy replay by many teams |
| Database table | Mutable records | Current state and transactions | Using it as a high-throughput event bus |
| Log compaction | Latest value by key | State change topics | Confusing compaction with time retention |
Kafka answer signals
Ordering, replay, and operations are the highest-value areas.
- Partitions: ordering, scale, keys
- Consumer groups: parallelism and offsets
- Reliability: acks, replicas, retries
- Operations: lag, retention, rebalances
How to Prepare for a Kafka Interview
Prepare by drawing a record's path from producer to broker to consumer. Then explain ordering, replay, failure handling, and lag.
- Review topics, partitions, brokers, replicas, leaders, followers, producers, consumers, and offsets.
- Know consumer groups, rebalancing, lag, commits, retention, compaction, and dead-letter topics.
- Practice delivery semantics: at most once, at least once, and exactly once within Kafka transactions.
- One incident story about lag, duplicate processing, bad partition keys, or schema changes is useful.
Kafka interview prep flow
Most rounds reward clear reasoning more than memorized phrasing.
How Strong Kafka Answers Sound
A strong Kafka coverage names the partition key, expected ordering, consumer group behavior, offset commit point, and retry path. production-ready answers also cover schema compatibility, idempotent producers, dead-letter topics, lag monitoring, retention, compaction, and what happens during broker or consumer failure.
Start with ordering
Kafka guarantees order within a partition, not across the whole topic.
Treat duplicates as normal
Retries and failures can create duplicate processing. Consumers should be idempotent when the business action requires it.
Lag is a symptom
Consumer lag may come from input spikes, slow processing, rebalances, bad partitions, or slow sinks.
Plan schema changes
Event producers and consumers evolve independently, so compatibility rules are part of the design.
Test Yourself: Kafka Quiz
Ready to test your Kafka knowledge?
6 questions, about 4 minutes. Score 70% or higher to earn a shareable certificate.
Frequently Asked Questions
What do Kafka interviews usually ask?
Is Kafka a message queue?
What Kafka project should I discuss?
What separates experienced Kafka candidates?
Prepare Kafka answers for data and backend rounds
Use this Kafka bank for architecture and incident answers, then practice SQL, Python, and pipeline tasks with Hyring's AI Coding Interviewer.
See Hyring AI Coding InterviewerSources
Written by Adithyan RK