Kafka Interview Questions: Ordering, Delivery and Consumer Lag

Almost every real Kafka question reduces to partitions. Ordering is per partition, parallelism is bounded by partition count, and the key decides the partition. Candidates who hold that one idea answer most follow-ups correctly.

So expect the key selection question. A key with poor cardinality creates a hot partition, which is a bottleneck that adding consumers cannot fix, and that surprises people who assume more consumers always means more throughput.

Be ready for what happens when you add partitions to an existing topic: the key to partition mapping changes, so ordering guarantees for a given key do not survive the change. This is a favourite because it is easy to miss and expensive in production.

Be exact about at most once, at least once, and exactly once. Most systems run at least once and build idempotent consumers, and saying that plainly is better than claiming exactly once casually.

Know that exactly once in Kafka is scoped to reading, processing and writing within Kafka. It does not extend to an external side effect such as sending an email or charging a card. That distinction is a strong signal.

Know where the commit happens relative to the processing, because that is what actually determines duplicates or loss. Committing before processing risks loss, after risks duplicates, and choosing deliberately is the answer.

Know what triggers a rebalance and what it costs: consumers stop while partitions are reassigned. A consumer that takes too long between polls is ejected, triggers a rebalance, and can enter a loop that looks like a broker problem but is a processing time problem.

Know the difference between slow consumers and stuck consumers, and how lag distinguishes them. Lag growing steadily is throughput; lag growing on one partition is a hot key or a poison message.

Have a position on handling a message that always fails. A dead letter topic with a retry limit is the expected answer, and being able to say what you do with the dead letter queue afterwards makes it a real answer rather than a named pattern.

The broker gives durability, ordering within a partition, and replay. Everything else is yours: deduplication, ordering across keys, schema compatibility, and whatever your downstream needs.

Be able to describe your idempotency mechanism specifically. A business key stored in a database with a uniqueness constraint is a normal and credible answer; saying the consumer is idempotent without a mechanism is not.

Have one incident: consumer lag climbing, a rebalance loop, or a schema change that broke consumers. The recovery detail is what makes it useful to an interviewer.