Kafka interview questions

Partitions, and what follows from them

• A topic is split into partitions; order is guaranteed within a partition, never across a topic. This is the single most important fact.
• How does a message get a partition? By key hash, or round-robin without a key - which is why picking a key is a design decision.
• What happens if your key choice is skewed? A hot partition, and one consumer doing most of the work.
• Partition count sets the maximum useful parallelism in a consumer group - more consumers than partitions means idle consumers.
• Why is increasing partition count later disruptive? It changes key-to-partition mapping and therefore ordering.

Consumer groups and offsets

• How do consumer groups divide partitions, and what triggers a rebalance?
• What is the cost of a rebalance? Processing stops - and this is a real production pain point worth naming.
• Offset commit strategies - auto-commit versus manual, and why auto-commit can lose or duplicate messages.
• What is consumer lag, and what do you do when it grows?
• What happens when a consumer dies mid-batch?

Delivery guarantees

• At-most-once, at-least-once, exactly-once - and which you get by default (at-least-once, with sensible settings).
• The exactly-once question. Kafka supports it within Kafka via idempotent producers and transactions, but end-to-end exactly-once including an external system usually means at-least-once delivery plus idempotent processing on your side. Saying that plainly is the strong answer.
• Idempotency keys, and designing consumers so reprocessing is safe.
• `acks=0`, `1` and `all`, and what each risks.
• Replication factor and in-sync replicas.

Operations and design

Retention by time or size and what compaction is for, why a dead-letter topic matters, and schema evolution with a registry. Then the design question: when is Kafka the wrong tool? For simple job queues with low volume it is heavy operational overhead, and saying so signals judgement. Surrounding architecture ground is in microservices interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus a topic design and a consumer you have operated. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: a rebalance storm or lag incident you resolved, and schema evolution across teams. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a Kafka interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common Kafka interview questions?

How partitioning determines ordering and parallelism, choosing a partition key, consumer groups and what triggers rebalances, offset commit strategies, and delivery guarantees including the exactly-once question.

Does Kafka guarantee message ordering?

Only within a partition, never across a topic. If you need ordering for a particular entity, you key messages by that entity so they land in the same partition. This single fact underlies most other Kafka interview answers.

Does Kafka support exactly-once delivery?

Within Kafka, yes - through idempotent producers and transactions. End to end, including an external database or API, you normally get at-least-once delivery and achieve effective exactly-once by making consumer processing idempotent. Stating that distinction clearly is the strong answer.

What happens during a Kafka consumer rebalance?

Partition assignments are redistributed across the group, and processing pauses while it happens. Frequent rebalances - caused by slow processing exceeding the poll interval, or unstable consumers - are a common production problem worth mentioning.