Tell me about a time you chose Kafka for a project and why
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question is usually less about Kafka itself and more about your engineering judgment in choosing a tool for a specific problem. Interviewers want to hear how you framed the problem, compared alternatives, understood tradeoffs, and made a decision appropriate to your level of scope. Strong answers also show that you connected the technology choice to concrete requirements and validated that the choice actually worked.
Key Insights
- You should spend more time on the problem and constraints than on Kafka trivia. The interviewer is evaluating your decision process, not whether you can recite features like partitions or consumer groups.
- A strong answer names credible alternatives and why they were not the best fit. 'Kafka is scalable' is weak unless you explain what scale, durability, ordering, or decoupling need made that matter in your case.
- Don't tell a story where Kafka was obviously overkill unless you can clearly justify the tradeoff. Experienced interviewers notice when candidates optimize for fashionable technology instead of the simplest solution that met the need.
What interviewers probe atlevel
Top Priority
You do not need an exhaustive architecture study, but you should show that Kafka was chosen over something realistic for a reason.
Good examples
đ˘We discussed using a cron-based batch job, but that would have introduced hours of delay and made failures harder to isolate. Kafka was more appropriate because the consumers needed near-real-time updates and separate retry behavior.
đ˘A direct API call was simpler, but it would have made the producer depend on downstream availability. Kafka added some complexity, but it gave us buffering and let the producer stay fast even if the consumer was slow.
Bad examples
đ´I didn't really consider alternatives because Kafka seemed like the strongest option and I knew it could handle anything we threw at it.
đ´The other option was just writing directly to the database, but that felt outdated compared with a streaming approach.
Weak answers compare Kafka to unrealistic straw alternatives or assume 'more capable' means better; strong answers compare against credible simpler options and explain the real tradeoff.
Valuable
Example answers atlevel
Great answers
On a project to send account update events to another internal service, I helped evaluate whether we should make a direct API call or publish events through Kafka. The main issue was that the downstream service sometimes had short outages, and we didn't want user requests in our service to fail just because that dependency was unavailable. Kafka made sense because it let us publish the event quickly, keep the user flow fast, and let the consumer catch up later. My role was gathering examples of failure cases from our logs and then implementing part of the producer side with some basic publish-failure metrics. After testing, we saw that updates still flowed through correctly even when we simulated the downstream service being slow, which matched the reason we picked it.
At my last internship on a retail analytics tool, I helped build a small pipeline that collected click and inventory updates from a few internal apps. We chose Kafka because the data didnât need to be processed instantly, but it did need to be delivered reliably even when one of the source systems was busy or temporarily offline. I was mainly responsible for comparing a few simpler options and writing a basic consumer that wrote the messages into our database. Kafka also gave us a cleaner way to add a second consumer later for reporting without changing the apps that were sending the data. For that project, I liked that it kept the sending side simple and made it easier for our small team to grow the system without rewriting everything later.
Poor answers
I used Kafka on a project where we needed to move data between services. I suggested it because Kafka is a standard tool for real-time systems and it's very scalable, so it felt like the best engineering choice. We already had some internal support for it, so there wasn't much reason to do something simpler. Once we had that direction, I built my part and the project shipped.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid August, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.