Interview & Revision

Short, precise answers to the most common warm-up questions. Own these cold so you can spend interview time on the harder ones.

These Kafka interview questions and answers cover the questions that decide whether the interview goes to the next round.

Walk me through what happens from producer.send() to the consumer reading the record

1. Serialization + partitioner. Producer serializes key/value, chooses a partition (key hash if key present, sticky otherwise).

2. Batching. Record goes into a per-(topic, partition) batch. Flushed when batch.size bytes is hit or linger.ms elapses.

3. Network. Producer sends ProduceRequest to the partition leader. Up to max.in.flight.requests.per.connection unacked batches on the connection.

4. Leader append. Leader appends the batch to its log at the next offsets, updates its log-end-offset.

5. Replication. Followers issue FetchRequests, pull the batch, append to their logs, update their LEOs.

6. ACK. With acks=all, once the full ISR's LEO reaches this batch's last offset, the leader acknowledges the producer.

7. HW advance. Leader updates the high-watermark based on the lowest LEO it has observed across the current ISR from recent follower fetches. Only records ≤ HW are visible to consumers.

8. Consumer fetch. Consumer sends FetchRequest to the leader with the offset it wants to read next (its position). Broker returns records up to HW via zero-copy sendfile().

9. Processing + commit. Consumer processes, then commits the offset of the next record to read (last processed offset + 1).

The interview line: "The commit-log design means step 4 dominates cost — everything else is byte shuffling."

How does Kafka guarantee ordering, and where does it break?

Guarantee: ordering is preserved per partition, per producer.

Where it breaks:

1. Multiple partitions. No ordering across partitions of the same topic. If ordering matters for a business key, send all records for that key to the same partition (i.e., supply the key and let the default partitioner do its job).

2. Multiple producers with the same key. Each producer has its own send buffer; interleaving depends on network timing. If two producers are updating the same aggregate, use a single producer or accept the interleaving.

3. `max.in.flight > 1` without idempotence. If batch 3 fails and is retried while batch 4 succeeded, you get [1, 2, 4, 3]. Idempotence + max.in.flight ≤ 5 fixes this because the broker enforces sequence-number ordering.

4. Repartitioning. Adding partitions changes the hash mapping — a key that went to partition 2 yesterday may go to partition 5 today. All ordering guarantees are relative to a fixed partition set.

How does rebalancing work, and how do you make it not hurt?

Trigger: membership change (join, leave, crash), subscription change, or partition count change.

Classic (eager) protocol:

1. Coordinator sends RebalanceInProgress to all members. 2. Every member calls revoke() on all its partitions — the whole group stops consuming. 3. Members rejoin, coordinator computes new assignment. 4. Members receive their new partitions and start again.

Cost: the entire group pauses for the duration. In big groups this can be seconds.

Cooperative sticky assignor (KIP-429): only the partitions being reassigned are revoked. Members that keep their partitions never stop. This is the answer to any 'rebalance storm' question in a modern interview.

Next-generation protocol (KIP-848): Kafka 4.0 made the new broker-driven consumer group protocol generally available, removing the group-wide synchronization barrier; consumers opt in with group.protocol=consumer, and the classic protocol above remains supported.

How to make it not hurt:

- Use CooperativeStickyAssignor. - Set session.timeout.ms higher than P99 GC + network jitter. - Set max.poll.interval.ms higher than P99 handler time × safety factor. - Use static membership (group.instance.id) for K8s pods with stable identity so pod restarts don't trigger rebalances. - Commit before you die (idempotent processing + at-least-once commit).

How do you scale a consumer group that is falling behind?

First find the real ceiling. Measure handler time, rebalance frequency, lag by partition, and downstream dependency latency before assuming Kafka is the bottleneck.

Ladder of moves:

1. Fix the handler first. Batch database writes, remove synchronous I/O, and cache expensive lookups.

2. Add consumers, up to partition count. Fastest way to increase parallelism when partitions are idle.

3. Add partitions only when parallelism is maxed out and you have a plan for key skew and ordering impact.

4. Split into separate consumer groups when different workloads need independent scaling or blast radius.

5. Reach for multi-cluster only for clear isolation or regional needs, not as the first scaling move.

Anti-patterns: adding partitions with no key/cardinality plan, committing every record, or scaling consumers when the real bottleneck is downstream.

What's the difference between at-most-once, at-least-once, and exactly-once?

At-most-once: commit the offset before processing. Crash mid-process → record is skipped. Fast, may lose data. Note that enable.auto.commit=true is not simply at-most-once: offsets are committed from inside poll(), so it behaves as at-least-once when processing finishes before the next poll(), and can lose records if processing is handed off asynchronously and the consumer crashes after the commit.

At-least-once: commit the offset after processing. Crash mid-process → re-read on restart → re-process. Never loses, may duplicate. Combine with enable.idempotence=true on producer and idempotent processing (e.g., upsert by primary key) to get effectively exactly-once at the application layer.

Exactly-once (Kafka EOS): - Producer: enable.idempotence=true + transactional.id. - Producer wraps send() calls in beginTransaction() / commitTransaction(). - Consumer: isolation.level=read_committed skips aborted writes. - Read-process-write: sendOffsetsToTransaction() atomically commits input offsets with output writes.

Gotcha: Kafka EOS is exactly-once within Kafka. External side effects (DB writes, emails, HTTP calls) still need idempotency on your side.

You see UnderReplicatedPartitions > 0 on one broker for 10 minutes. What do you do?

First, assess severity before reflexively declaring a P1 — how many partitions, which topics, is the ISR still ≥ min.insync.replicas, is any write actually being rejected, and how long has it persisted? A brief blip during a rolling restart is routine; a sustained shrink on a topic with little ISR headroom is genuinely urgent. Once you've judged it worth escalating:

Diagnosis order:

1. Which partitions? kafka-topics --describe --under-replicated-partitions. 2. Which broker is behind? Cross-reference with per-follower LEO — usually one specific broker. 3. Why is that broker lagging? - Disk saturated: check LogFlushTimeMs, RequestQueueSize. - Network saturated: check NetworkProcessorAvgIdlePercent. - Fetcher starved: num.replica.fetchers too low for the broker's leader count. - JVM GC: long pauses drop the follower from ISR. 4. Fix root cause. Don't just restart — restarting the broker while it's the leader for something else triggers a leader election and shifts the pain elsewhere.

If the broker is truly stuck: move partitions off it with kafka-reassign-partitions.sh and cordon it while you investigate.

Design a system that consumes from Kafka and writes to Postgres exactly once

Approach 1 — idempotent upserts. Include the Kafka (topic, partition, offset) as a natural key in the target table (or a dedicated processed_events table). On restart, INSERT ... ON CONFLICT DO NOTHING. Commit Kafka offsets after the transaction. This is at-least-once + application-level idempotency.

Approach 2 — transactional outbox in reverse. Store the last processed offset in the same Postgres transaction as the write. On startup, seek to that offset. Guarantees exactly-once end-to-end because either both the write and the offset land, or neither does.

Approach 3 — Kafka Connect with a JDBC sink. Connect handles offset management via its internal offset topic, but end-to-end exactly-once into an arbitrary external database is not automatic — it depends entirely on what the specific connector documents and supports. Verify the exact guarantee for the connector and version you're using rather than assuming it.

Interview line: "Kafka's EOS ends at Kafka's boundary. Anything past that boundary — DB, cache, external API — you make idempotent or you use a transactional outbox."

The refresher for the morning of the interview. Read once, own the fundamentals.

Concepts

Topic = named log · Partition = unit of ordering + parallelism · Offset = position in partition.

Consumer group: one partition owned by exactly one member → max parallelism = partition count.

Replication: RF copies, one leader, rest followers. ISR = followers caught up.

acks=all + min.insync.replicas=2 + unclean.leader.election.enable=false = durable against a single broker failure, provided at least one in-sync replica survives.

High-watermark = min(LEO) across ISR; only records ≤ HW are consumable.

Idempotent producer: PID + seq → exactly-once per partition write.

Kafka transactions: transactional.id + read_committed → exactly-once across multiple partitions.

Performance facts

Kafka gets much of its read efficiency from page cache via sendfile().

Its happy path is sequential append + sequential fetch, so hotspots are often skew, downstream processing, or network before they are "Kafka is slow."

Batching + compression are usually the highest-leverage producer-side wins.

Common pitfalls

enable.auto.commit=true → duplicates or loss on crash.

unclean.leader.election.enable=true → silent data loss on failover.

Adding partitions later → breaks key-based ordering going forward.

One topic for everything → coupling of retention, schema, ACLs.

Skipping schemas → schema-evolution failures in production.

A few deeper topics that still earn their place in interview revision.

Log compaction

Compaction is key-based, not age-based: Kafka eventually keeps the latest value per key, and a null value acts as a tombstone. It is asynchronous, so older values and tombstones can remain visible on disk for a while. Offsets are not renumbered after compaction — gaps are normal. This matters because compacted topics are how changelog/state-rebuild patterns work.

KRaft metadata architecture

KRaft is Kafka's Raft-based metadata quorum, replacing ZooKeeper. The key interview point is architectural: metadata is now managed by a controller quorum, not by an external coordination system. Older material that treats ZooKeeper as Kafka's live control plane is historical context, not the modern default.

Multi-cluster replication (MirrorMaker 2)

MirrorMaker 2 replicates Kafka data between clusters, but Kafka replication is not the same thing as application disaster recovery. It helps with topic/offset movement; it does not solve traffic failover, external database state, or business-level conflict resolution for you.

The scenario questions that separate "knows the configs" from "has actually operated this." These are reasoning exercises, not trivia — walk the guarantee → mechanism → failure mode → recovery ladder out loud.

One celebrity key is suddenly responsible for 80% of traffic — what do you do?

Strong answer direction: First confirm it with evidence: per-partition produce/fetch rates, broker leader-skew, and consumer lag concentrated on specific partition numbers. The fix depends on whether ordering matters for that key. If it doesn't, add a bounded random salt to the key so that one logical entity's traffic spreads across multiple partitions. If ordering must be preserved for that key, spreading isn't safe — instead consider isolating the hot entity onto dedicated topic/partition capacity, or restructuring how work for it is modeled so a single partition isn't the bottleneck.

What this tests: Whether the candidate reaches for 'add more partitions' reflexively versus diagnosing whether the partitioner is actually the constraint.

Consumer lag is zero, but customers say they're not receiving updates — what's going on?

Strong answer direction: Zero lag only tells you the consumer has read up to the log end — it says nothing about whether the consumer's processing actually succeeded or reached the customer. Possible causes: the consumer is committing offsets before (or regardless of) a failed downstream write, so it silently drops work while still advancing; it's reading the wrong topic/partition subset for the affected customers; a downstream service (notification, cache, search index) is failing independently of Kafka; or the business logic has a bug unrelated to Kafka's delivery. This is exactly why consumer lag alone is an insufficient signal — pair it with an end-to-end freshness metric (e.g. 'oldest unprocessed business event age' or a synthetic canary record) that reflects actual downstream success.

What this tests: Whether the candidate conflates 'Kafka is healthy' with 'the business outcome happened' — a very common and costly interview (and production) mistake.

ISR is fully healthy, but producer p99 latency suddenly spikes — where do you look?

Strong answer direction: A healthy ISR rules out the most obvious durability-related cause, so look elsewhere: GC pauses on the leader broker (check JVM metrics even if ISR hasn't shrunk — a pause can delay acks without yet causing a full ISR drop), disk flush latency (LogFlushRateAndTimeMs), network-processor saturation on the broker, a sudden increase in produce request size or rate from a different client, or a client-side change (e.g. someone dropped linger.ms to zero, or batch sizes shrank, increasing per-request overhead). Correlate the timing precisely against deploys, traffic shifts, and broker-level resource metrics before assuming it's a Kafka-side problem at all.

What this tests: Whether the candidate can reason past the first explanation (ISR/durability) to broker resource and client-behavior causes.

Cross-region replicated Kafka (via MirrorMaker 2) is reporting healthy, but application disaster recovery still fails during a region outage — why?

Strong answer direction: Replicating Kafka's data is not the same as making the application DR-ready. MirrorMaker 2 keeps topics/offsets/ACLs in sync between clusters, but it doesn't automatically handle: application failover routing (DNS, service discovery pointing at the new region), active-active write-conflict resolution if both regions can produce, the state of external databases the application also depends on (which MM2 never touches), or exactly-once semantics for business processing that spans the region failover. "Kafka data replicated" and "application survives a regional failure" are two different engineering problems that both need to be solved.

What this tests: Whether the candidate separates infrastructure replication from application-level disaster recovery — a distinction many engineers conflate.

Beyond the questions, what does mastery of Kafka look like in practice?

A senior engineer knows the configs. A staff engineer knows why each config exists and what its absence would cost. That difference is what interviewers are really probing for.

The staff-level pattern of thought looks like this: "What guarantee does the system give me?" → "What mechanism produces that guarantee?" → "What failure mode does that mechanism assume?" → "How do I detect and recover if that assumption breaks?" Every deep Kafka question can be answered by walking that ladder. Every shallow answer skips it.

For example: "How is durability guaranteed?" A junior answers replication. A senior answers RF=3 + acks=all. A staff engineer answers: RF=3 + acks=all + min.insync.replicas=2 + unclean.leader.election=false + idempotence + monitor UnderReplicatedPartitions and consumer lag and know that if the ISR shrinks to 1 you'll get NotEnoughReplicasException which is the intended behavior because we chose to fail loudly rather than silently be one failure from data loss. Same question. Wildly different level of understanding.