Back to interview questions
By
Team Sherlock.sh
Kafka interviews should reveal whether a candidate can reason about a durable partitioned log, not simply name messaging patterns. Recruiters hiring backend engineers, data engineers, or streaming-platform specialists need evidence that candidates understand record ordering, replication, consumer progress, and the difference between a successful API call and a business outcome.
These 120 questions move from Kafka vocabulary and client usage to transaction boundaries, stream processing, and production diagnosis. Unlike a general microservices or system-design interview, the emphasis is on Kafka-specific mechanisms: which replicas acknowledge a write, which offset is safe to commit, why a group rebalances, and what an operator should verify before changing a running cluster.
How can recruiters tell whether a candidate can diagnose a Kafka failure rather than repeat streaming terminology?
Ask the candidate to trace one record through a producer retry, a leader failure, and a consumer restart. Then change an acknowledgment or offset setting and ask which outcomes become possible.
Sherlock AI helps recruiters assess signals of potential AI cheating, deepfakes, impersonation, and unauthorized assistance during interviews.
Treat those signals as context for careful assessment, not conclusive proof of misconduct. Kafka-specific follow-up questions and small failure scenarios give candidates a concrete way to demonstrate their reasoning.
Kafka Interview Questions
Select an interview path from the complete bank before consulting the answers. The three levels progress from the log and its clients to operational evidence, recovery, and integration boundaries.
Kafka Interview Questions for Beginners
Establish the candidate’s understanding of records, topics, partitions, clients, replication, and retention before introducing operational edge cases.
What is Apache Kafka, and what problem does it solve?
What information does a Kafka record contain?
What is a Kafka topic?
Why are Kafka topics divided into partitions?
How does a broker differ from a controller in Kafka?
How do Kafka producers and consumers interact?
Why does a Kafka record key matter?
What ordering guarantee does Kafka provide?
What is a consumer group?
What is a Kafka offset?
How does a consumer's position differ from its committed offset?
How can Kafka consumers replay historical events?
What does replication factor mean?
What do partition leaders and followers do?
What is the in-sync replica set?
How do the producer's acks settings differ?
How does min.insync.replicas work with acks=all?
What is KRaft in Apache Kafka?
Does Kafka 4.x still require ZooKeeper?
Why do Kafka producers need serializers and consumers need deserializers?
What does bootstrap.servers configure?
How would you create and inspect a topic using Kafka's CLI?
How can you perform a basic console producer and consumer check?
What does a minimal Java Kafka producer look like?
What does the consumer poll loop do?
When does auto.offset.reset apply?
What is risky about automatic offset commits?
What is consumer lag, and what does it tell you?
How does time-based or size-based retention work?
How does log compaction differ from delete retention?
What is a tombstone in a compacted topic?
What is the difference between event timestamps and processing time?
What are Kafka record headers used for?
How do batch.size and linger.ms affect producers?
Why can compression improve Kafka performance?
Why can producer retries create duplicates?
How should you choose a topic's partition count?
How do consumer fetch settings differ from max.poll.records?
How do client.id and group.id differ?
When is Kafka a poor fit for a workload?
Kafka Interview Questions for Intermediate
Explore producer tuning, safe offset management, consumer coordination, transactions, and practical use of Streams and Connect.
How would you diagnose producer buffer exhaustion?
Why should producer callbacks avoid slow application work?
How do max.block.ms, request.timeout.ms, and delivery.timeout.ms differ?
Which settings must remain compatible with Kafka producer idempotence?
When can producer retries change record order within a partition?
What should an application do when a producer send has an ambiguous outcome?
What is the lifecycle of a transactional Kafka producer?
Why can a read_committed consumer stop before the partition's latest records?
How can consumed offsets and produced records be committed atomically?
Why do Kafka transactions not automatically make database writes exactly once?
When should a consumer use synchronous versus asynchronous offset commits?
Which offset should a consumer commit after processing a batch?
How should a consumer shut down without acknowledging unfinished work?
What should a rebalance listener do with in-flight records?
How do eager and cooperative rebalancing differ under the classic protocol?
What changes when a Kafka 4.1 consumer uses group.protocol=consumer?
When is static consumer membership useful, and what can go wrong?
How should a multithreaded application use KafkaConsumer safely?
How do pause and resume help with consumer backpressure?
How would you distinguish consumer lag caused by capacity from lag caused by a stall?
When is manual partition assignment appropriate instead of subscribe?
How can a consumer replay records from a timestamp?
How should a consumer handle a poison record without hiding data loss?
How should segment rolling influence a retention investigation?
What does cleanup.policy=compact,delete mean?
Why can a compacted topic accumulate a large dirty log?
How should teams manage event schema evolution in Kafka?
How do Kafka Connect connectors, tasks, and workers differ?
What is the difference between Connect converters and single message transforms?
What are the limits of Kafka Connect error tolerance and dead-letter queues?
How do source and sink connectors track progress differently?
How do KStream and KTable represent data differently?
Why does a Kafka Streams topology sometimes need repartitioning?
How do event-time windows and grace periods affect late records?
How does Kafka Streams recover local state after a failure?
What does processing.guarantee=exactly_once_v2 provide in Kafka Streams?
How do TLS, SASL, and ACLs address different Kafka security needs?
How would you apply least privilege to a Kafka application?
Why can a large Kafka record fail even after increasing max.request.size?
What happens if you change a producer's key serialization or partition count?
Kafka Interview Questions for Experienced
Use these scenarios to assess incident diagnosis, capacity planning, migrations, security boundaries, stateful processing, and disaster recovery.
How would you reason about durability when a three-replica partition loses two replicas?
How does transactional fencing prevent a zombie producer from continuing?
When is an unclean leader election an unacceptable recovery choice?
How should replica placement change when brokers span availability zones?
How would you respond to a Kafka broker whose disks are almost full?
What happens when a KRaft controller quorum loses its majority?
Why might you separate KRaft controller processes from broker processes?
What should you verify before attempting KRaft metadata recovery?
How would you plan an upgrade from a ZooKeeper-based Kafka 3.x cluster to Kafka 4.1?
What compatibility assumptions should be revisited when adopting Kafka 4.x clients?
How would you evaluate follower fetching for a multi-zone consumer?
How would you estimate Kafka storage and network capacity?
What would you do when one Kafka partition is much hotter than the others?
How would you calculate whether a consumer can catch up before retention expires?
Which monitoring signals should drive a Kafka production incident response?
How would you move Kafka replicas without causing an avoidable outage?
How do Kafka quotas help with noisy neighbors, and what do they not solve?
How would you rotate Kafka credentials without creating an avoidable outage?
How would you diagnose a client that connects to bootstrap servers but cannot produce?
Why can a consumer fail to reconstruct state even when its topic uses compaction?
What consistency and routing concerns arise with Streams Interactive Queries?
When would a GlobalKTable be preferable to a partitioned KTable?
How can idle inputs affect ordering in multi-input Streams operations?
Why can a Streams aggregation emit fewer updates than input records?
How do standby replicas change a stateful Streams application's recovery trade-offs?
How would you safely deploy a change to a stateful Kafka Streams topology?
Why do null values and tombstones require special care in Streams joins?
What must be true for Kafka Connect source exactly-once support to be meaningful?
Why does a Kafka Connect sink need destination-specific support for exactly-once effects?
Why must Connect internal topics be treated as critical shared state?
How would you investigate a Connect source that resumes from the wrong position?
Why might increasing Connect tasks.max fail to improve throughput?
How would you define event identity across republishing and schema migrations?
What should a cross-cluster Kafka disaster-recovery design promise about data loss?
Why can consumer offsets not simply be copied numerically during cross-cluster failover?
How would you avoid the database-and-Kafka dual-write problem?
How would you make a production replay safe for downstream systems?
When would you choose separate Kafka clusters instead of shared-cluster multi-tenancy?
How would you test Kafka recovery without confusing a restart test with a resilience test?
What evidence would you require before declaring a Kafka pipeline production-ready?
Kafka Interview Questions and Answers
The answers reproduce the bank in the same order and connect each explanation to an example, a trade-off, or a failure condition. This guide uses Apache Kafka 4.1 as an explicit, consistent baseline, not as a claim that it is the latest release. It covers standard consumer groups rather than preview share groups unless stated otherwise. Kafka 4.x is KRaft-only; ZooKeeper discussion is historical migration context. Check the documentation matching deployed brokers, Java clients, Streams, and Connect. Examples are illustrative and were not executed against a Kafka broker.
Kafka Interview Questions and Answers for Beginners
These answers make foundational Kafka behavior explicit. Probe the examples to check whether a candidate distinguishes per-partition guarantees from application-wide assumptions.
1. What is Apache Kafka, and what problem does it solve?
Apache Kafka is a distributed event-streaming platform that stores ordered records in partitioned logs and lets applications publish and consume them independently. Its useful distinction is durable, replayable history: reading an event does not normally remove it. Different applications can therefore derive different results from the same stream.
For example, a payment event can feed a reconciliation service and an analytics pipeline without making either service responsible for forwarding it to the other. The interviewer should hear how retention, keys and consumption positions support that workflow, not just “Kafka is a message queue.” Kafka does not automatically validate business events, provide arbitrary queries over them, or make downstream database writes atomic.
2. What information does a Kafka record contain?
A Kafka record carries a value and can also have a key, timestamp and headers. Once appended, its topic, partition and offset identify its location. The key and value are serialized bytes on the wire; the application chooses their meaning. A key such as an account ID may guide partition selection, while the value describes an account event.
Consider an order event with key order-72, a JSON value and a correlation-ID header. The offset tells a consumer where that record sits within one partition; it is not the order's business identifier. Applications should keep durable event identifiers inside their data when needed for deduplication or auditing, because copying a record to another topic assigns a different location.
3. What is a Kafka topic?
A topic is a named stream of records, divided into partitions, with policies such as retention and replication. Producers write to it and consumers read from it. A useful topic boundary usually reflects a coherent event contract and operational requirements, rather than simply mirroring every application class.
For example, orders.events might contain order lifecycle events consumed by several teams. Its schema, ownership and retention period need an explicit agreement even though Kafka itself accepts serialized bytes. Topics do not guarantee a single order across all their partitions, and their names do not enforce access permissions. Creating separate topics can isolate retention or authorization, but thousands of unnecessary topics and partitions also increase operational overhead.
4. Why are Kafka topics divided into partitions?
Partitions divide a topic into independent ordered logs, enabling storage and processing to spread across brokers and consumers. Each partition has its own offsets and leader. This is the unit around which Kafka's ordering and ordinary consumer-group parallelism are organized.
If an event topic has six partitions, a conventional consumer group can assign those partitions across up to six actively consuming members; adding a seventh member does not create a seventh partition assignment. More partitions are not free: they add metadata, replica work and recovery overhead. Start with expected throughput and key distribution, then test realistic workloads. A single very hot key can still concentrate traffic in one partition despite a high topic-wide partition count.
5. How does a broker differ from a controller in Kafka?
A broker serves data-plane operations such as producing, fetching and storing partition replicas. A KRaft controller participates in managing cluster metadata and coordinating decisions such as partition leadership. These are different roles even when a development node runs both.
For example, a consumer fetches order records from the relevant brokers; it does not stream every record through the active controller. In a production design, separating controller and broker processes can isolate metadata availability from heavy data traffic. A controller quorum is also not the same as a topic's replication factor: three controllers do not imply that every topic has three replicas. Troubleshooting should establish whether the failure affects metadata decisions, record serving, or both before changing settings.
6. How do Kafka producers and consumers interact?
A producer serializes records and sends them to topic partitions. A consumer fetches records and tracks its progress through those partitions. They communicate through Kafka rather than requiring both applications to be simultaneously available for a direct request-response exchange.
For instance, an inventory producer can keep writing while an analytical consumer is temporarily offline, provided the cluster remains writable and retained data outlasts the outage. When the consumer returns, it can resume from its committed offsets. That decoupling is bounded by capacity, retention and processing speed; Kafka is not infinite storage. A producer acknowledgement also says nothing about whether a downstream consumer has completed a business action, so an application needing that confirmation must model it explicitly.
7. Why does a Kafka record key matter?
A key can determine partition placement and provides the identity used by log compaction. With the usual keyed partitioning behavior, records whose serialized keys are equal map to the same partition while the partitioning scheme and partition count remain stable. This supports ordered processing for an entity.
An account ID is therefore often more useful than a random event ID when account-level sequence matters. However, a dominant account can become a hot key and bottleneck one partition. Changing the key serializer or increasing the partition count can change routing. The application must treat key encoding and partitioning as part of its contract, not assume that an identical displayed string always produces identical bytes across every client implementation.
8. What ordering guarantee does Kafka provide?
Kafka provides an ordered log within each partition, not one global order across an entire multipartition topic. Consumers observe records according to their partition positions, but application code can still reorder completion by dispatching them to parallel workers.
Suppose account A's debit and credit reach the same partition in the intended producer order. A consumer can process them sequentially. If it sends both to an unordered thread pool, the credit may complete first even though Kafka delivered the debit first. Multiple producers also need a business sequencing strategy if their events have causal dependencies. Producer retry settings matter when idempotence is disabled, so “same key” alone is not a complete end-to-end ordering explanation.
9. What is a consumer group?
A consumer group coordinates consumption among application instances using a shared group identity. Under conventional subscription-based consumption, a partition is assigned to at most one member of the group at a time. Different groups independently read the same topic and maintain separate progress.
For example, three billing workers can share billing-v1, while a reporting service uses reporting-v1. Billing's offset commits do not advance reporting's offsets. Giving unrelated applications the same group ID can accidentally split records between them instead of delivering every record to both. Conversely, giving every worker a unique group ID creates independent consumption rather than workload sharing. Group assignment also does not prevent duplicate processing after failures, since records may be re-read before a successful progress commit.
10. What is a Kafka offset?
An offset is a record's position within one partition. Offsets increase as records are appended and let consumers describe where to resume. They are not unique across the topic: partition 0 and partition 1 can both contain offset 200.
A location such as topic orders, partition 2, offset 200 is therefore meaningful; offset 200 by itself is incomplete. Retention and compaction can remove records without renumbering later records, so visible offsets need not form a gap-free sequence. Offsets also should not be mistaken for a count of business events successfully processed. When calculating throughput or diagnosing missing events, combine partition positions with retention, transaction visibility and application outcomes rather than assuming every numeric difference represents available records.
11. How does a consumer's position differ from its committed offset?
The position is where a running consumer will fetch next; the committed offset is the saved restart position for its group. Fetching records can advance position before application processing finishes, whereas a commit should represent progress the application can safely resume after.
If a poll returns offsets 50 through 59, its position can be 60 while the last committed offset remains 50. After successfully processing the batch, the application normally commits 60, meaning the next record to process. A crash before that commit may cause replay. Committing 60 before processing finishes may instead skip unfinished work after restart. This distinction matters more than memorizing commit APIs because it explains the failure behavior of real consumer loops.
12. How can Kafka consumers replay historical events?
Consumers can replay retained events by using a new group with an appropriate starting policy, explicitly seeking assigned partitions, or performing a controlled offset reset. Replaying changes where consumption begins; it does not recreate records already removed by retention or compaction.
For example, a new fraud-model evaluation group can read historical payments without disturbing the production fraud group's offsets. Before replaying into a live sink, decide whether repeated writes are harmless: sending a second customer notification is different from rebuilding a replaceable analytical table. A seek changes the current consumer position, not automatically every durable group offset. Operational resets should be scoped carefully, usually with the target group inactive, and verified before restarting consumers.
13. What does replication factor mean?
Replication factor is the configured number of replicas for each topic partition, including its leader. A replication factor of three means three copies placed on brokers, not three partitions and not three independent records exposed to a consumer.
For a topic with four partitions and replication factor three, the cluster maintains twelve partition replicas. Replication consumes disk and network capacity but allows suitable surviving replicas to take over when a broker fails. It is not a backup against every error: an application writing incorrect data can replicate that error, and retention policies apply to the replicated logs. Durability also depends on acknowledgement policy, in-sync replicas, placement across failure domains and recovery choices, not replication factor alone.
14. What do partition leaders and followers do?
A partition leader handles the partition's normal writes, while followers replicate its log. Kafka can elect an eligible replica as the new leader after failure. Consumers ordinarily fetch from leaders, although configured follower fetching can support more specialized locality arrangements.
Imagine replicas on brokers A, B and C, with A leading. When A fails, a sufficiently caught-up eligible replica can become leader and clients refresh metadata to find it. The application should expect temporary errors or retries during that transition rather than hardcode a broker as the permanent owner. Balanced leadership also matters: even with evenly distributed replicas, concentrating busy leaders on one broker can overload its network or CPU while other brokers appear underused.
15. What is the in-sync replica set?
The in-sync replica set, or ISR, contains replicas Kafka considers sufficiently caught up with the partition leader; the leader is normally a member. ISR membership changes as replicas fall behind or recover. It is therefore different from the full configured replica assignment.
For example, a partition may have three replicas but only two in the ISR because one broker is slow. That distinction affects whether writes satisfying a minimum-ISR policy can succeed. A falling ISR is an operational signal to investigate disk, network, broker pauses or replica-fetching capacity, not merely a reason to relax durability settings. “In sync” should not be described as a promise that every replica has the identical end offset at every instant.
16. How do the producer's acks settings differ?
acks=0 does not wait for a broker acknowledgement, acks=1 waits for the leader's acknowledgement, and acks=all waits for the required in-sync replication acknowledgement. These settings trade acknowledgement strength against availability and latency, and they must be interpreted together with replication and minimum ISR.
If a leader acknowledges under acks=1 and fails before another replica receives the record, the acknowledged write can be lost during failover. acks=all strengthens that outcome but does not mean every configured replica must always respond: replicas outside the ISR are not equivalent to in-sync replicas. Nor does an acknowledgement mean a consumer processed the event or every disk was synchronously flushed. A good answer states exactly which boundary has been acknowledged.
17. How does min.insync.replicas work with acks=all?
min.insync.replicas establishes the minimum ISR size required for writes using acks=all; it is a durability-versus-write-availability guardrail. It does not increase replication factor or turn acks=1 into a stronger acknowledgement policy.
With replication factor three and minimum ISR two, writes can continue when one replica is unavailable, provided the remaining ISR satisfies the requirement. If only one remains, those writes fail rather than accept a weaker replication outcome. Importantly, acks=all is not simply “acknowledge any two replicas”: when the ISR contains three members, its replication acknowledgement behavior involves that in-sync set. With Kafka 4.1 ELR enabled, high-watermark advancement is also blocked below the minimum ISR, independently of the producer acknowledgement setting. A weaker acknowledgement therefore does not ensure immediate consumer visibility. Applications must handle failed or ambiguous writes safely; operators should repair replication rather than reflexively lower the minimum.
18. What is KRaft in Apache Kafka?
KRaft is Kafka's metadata-management architecture built around a Raft-based controller quorum. It replaces the separate ZooKeeper dependency for cluster coordination. Brokers still hold and serve topic data; the metadata quorum does not replace ordinary partition replication.
For example, controller metadata records describe topics, partition assignments and broker state, while an orders partition contains application records. A deployment plan therefore needs both controller-quorum resilience and broker-data resilience. Losing a controller majority impairs metadata progress even if brokers still have data, and losing topic replicas can impair data availability even if controllers are healthy. In this article's Kafka 4.1 scope, KRaft is the relevant operating model rather than an optional alternative to a ZooKeeper-based deployment.
19. Does Kafka 4.x still require ZooKeeper?
No. Kafka 4.x uses KRaft and has removed ZooKeeper mode. Explanations that tell someone to start ZooKeeper as a mandatory first step describe older Kafka deployments, not the Kafka 4.1 baseline used here.
An interview can still ask about ZooKeeper when discussing a legacy estate or migration history, but the candidate should name the version boundary. An existing ZooKeeper-based cluster needs the supported migration and upgrade sequence before moving into 4.x; simply replacing its broker binaries is not a migration plan. Likewise, old properties and operational commands should not be copied into a new KRaft setup without checking their replacements. Separate an understanding of historical architecture from advice for configuring a current 4.x cluster.
20. Why do Kafka producers need serializers and consumers need deserializers?
Serializers turn application keys and values into bytes; deserializers interpret those bytes on the consumer side. Both sides must agree on the encoding and the evolution rules. A string serializer does not, by itself, validate that a string contains a compatible JSON business event.
For example, changing amount from a number to a formatted currency string may break a consumer even though Kafka successfully stores the bytes. Agree on a schema, test compatibility and plan how old records remain readable during replay. Apache Kafka core does not include a universal vendor Schema Registry service; teams may add a registry or other schema-governance tooling separately. The registry's compatibility settings and wire format are then additional deployment contracts, not automatic broker guarantees.
21. What does bootstrap.servers configure?
bootstrap.servers supplies initial broker addresses a client can contact to discover cluster metadata. It is not a complete permanent routing table and does not force all traffic through the first listed broker. After discovery, the client connects to the brokers responsible for its work.
Listing several reachable bootstrap brokers improves startup resilience. However, a successful bootstrap connection does not prove the deployment is usable: broker-advertised addresses must also be reachable from the client's network. For example, a laptop might reach a public bootstrap endpoint but receive internal hostnames it cannot resolve. Diagnose DNS, routing, listeners and authentication together rather than endlessly changing the bootstrap list. Controller-quorum endpoints are a separate configuration concern, not substitutes for ordinary broker bootstrap addresses.
22. How would you create and inspect a topic using Kafka's CLI?
Use kafka-topics.sh against a broker bootstrap address, declaring the intended partition count and replication factor, then describe the topic to inspect its assignment. The following commands assume an already-running disposable local cluster with at least three brokers and a new topic name; they are illustrative, not an executed setup.
The output helps check leaders, replicas and ISR rather than merely confirming a name exists. A one-broker sandbox cannot satisfy replication factor three; using one there demonstrates mechanics, not production resilience. Authenticated clusters require the appropriate client configuration. Avoid treating automatic topic creation as a substitute for deliberate retention, ownership and durability settings.
23. How can you perform a basic console producer and consumer check?
Kafka's console tools can demonstrate writing and reading records, making them useful for a small connectivity check. In separate terminals against an existing disposable local cluster and the already-created topic, run:
Type a test line into the producer terminal and observe it in the consumer. This checks a narrow happy path; it does not prove failover, application deserialization or processing correctness. --from-beginning concerns starting position and does not override an existing valid committed position in every group scenario. Use a fresh test group when testing historical consumption deliberately, and do not inject test records into a production business topic.
24. What does a minimal Java Kafka producer look like?
A Java producer needs broker bootstrap addresses and serializers, then sends ProducerRecord instances. This method-body example assumes Kafka 4.1 client dependencies, the corresponding imports, an existing disposable topic and a local broker; it is illustrative and has not been compiled or run here.
The enclosing method must handle exceptions from get(). Waiting on each send makes the example's acknowledgement visible but sacrifices throughput; production code commonly uses asynchronous callbacks and bounded error handling instead. Reuse producer instances rather than constructing one per event, and do not mistake idempotent transport retries for deduplication of independently submitted business events.
25. What does the consumer poll loop do?
The poll loop asks the client for records and gives the application an opportunity to process them repeatedly. Its design must coordinate processing time, assignment changes and offset commits. It is not enough to call poll() once and assume a background thread finishes the application's work.
For example, a worker can poll a bounded batch, process records sequentially, then commit only completed progress. If one batch takes too long relative to max.poll.interval.ms, group membership can be disrupted even when the broker is healthy. Reducing max.poll.records may help bound work per call, but it is not a substitute for diagnosing a slow database or unbounded retry. The Java consumer is not generally thread-safe, so parallel processing requires deliberate ownership and progress tracking.
26. When does auto.offset.reset apply?
auto.offset.reset determines what a consumer does when it has no valid committed offset for an assigned partition, including when the saved offset is no longer available. It does not routinely override a valid committed position on every restart.
For example, a new group using earliest begins at the earliest retained data, not necessarily the first record ever produced. A group using latest starts near the current end and can miss historical data by design. Choosing none makes the missing-offset condition an error that the application must handle. This setting should reflect recovery requirements rather than a copied default. If a reporting service unexpectedly loses a day's events, first establish whether retention invalidated its offsets before blaming deserialization or topic ordering.
27. What is risky about automatic offset commits?
Automatic commits periodically save consumer progress, but they do not inherently know whether every external side effect associated with fetched records has safely completed. The danger is confusing a fetched position with a successfully processed position, especially when work is handed to asynchronous workers.
Suppose a poll retrieves ten records and the loop immediately polls again while a thread pool processes them. Progress may be committed before a failed worker finishes, allowing unfinished work to be skipped after restart. Manual commits give more control, but they also require correct bookkeeping and failure handling. The right interview answer explains the processing boundary, replay tolerance and sink idempotency; it does not claim that disabling auto-commit alone creates exactly-once delivery or atomically coordinates a database transaction.
28. What is consumer lag, and what does it tell you?
Consumer lag usually describes the distance between a consumer's progress and a partition's end position, with the exact meaning depending on whether the metric uses committed offsets or the running fetch position. Increasing lag suggests consumption is not keeping pace, but it does not by itself identify the bottleneck.
For example, a consumer can fetch quickly and accumulate a large application work queue while committed progress remains slow. Conversely, aggressive commits can make offset lag look healthy even while business writes fail. Inspect lag per partition, arrival and completion rates, processing latency and sink health. Offset differences are also not always exact record counts because of gaps and transaction visibility. Event age is a useful complementary measure when user-facing freshness matters.
29. How does time-based or size-based retention work?
Retention determines how long or how much log data Kafka keeps under the delete policy, independently of whether consumers have read it. Cleanup operates on log segments, so a retention threshold is not a promise that each individual record disappears at an exact second.
For example, if a topic retains three days of data but a consumer is offline for five days, resuming from its old position may be impossible. Increase the retention window based on plausible outages and replay requirements, while budgeting disk for throughput, replicas and overhead. Size limits are applied at the partition level, which matters when estimating a topic's total footprint. A consumer acknowledgement or offset commit does not automatically delete a record for other groups.
30. How does log compaction differ from delete retention?
Log compaction removes superseded values for the same key over time, retaining a useful latest-value history for rebuilding keyed state. Delete retention removes old segments based on time or size. They solve different problems and can be configured together when the intended retention contract permits it.
A compacted customer-preferences topic can help a new service reconstruct the most recent known preference for each customer. It is not a snapshot that instantly contains exactly one record per key: older values may remain until cleaning runs, and consumers must tolerate them. Compaction also preserves offsets rather than renumbering surviving records. If an audit requires every change indefinitely, treating a compacted topic as the complete historical ledger would be a serious design mistake.
31. What is a tombstone in a compacted topic?
A tombstone is a record with a key and a null value that represents deletion of that key's state in a compacted topic. It is different from a JSON string containing null or an empty byte array, which are non-null serialized values unless the serializer explicitly maps them otherwise.
For example, a state-building consumer that reads a tombstone for customer-18 should remove that customer's entry from its local table. Tombstones themselves have retention behavior, so a consumer that remains offline too long may miss a deletion and retain stale state. Recovery planning must account for that window, not just the topic's general retention settings. Compaction is asynchronous, and producing a tombstone does not instantly erase every earlier physical copy or downstream replica of the business data.
32. What is the difference between event timestamps and processing time?
An event timestamp describes when an event occurred or the timestamp assigned to its record, while processing time describes when an application handles it. Kafka topics can use producer-supplied creation timestamps or broker append timestamps, depending on configuration; neither automatically proves the real business event time is accurate.
For example, a mobile device can upload yesterday's purchase today. A consumer processing it now should not blindly group it into today's business totals if the calculation is defined by purchase time. Clock skew, delayed arrival and retries complicate timestamp interpretation. Preserve a clearly defined business timestamp when needed, state its timezone and validation rules, and distinguish it from ingestion latency when investigating whether a pipeline is slow or its source is simply sending old events.
33. What are Kafka record headers used for?
Headers carry additional key-value metadata alongside a record's key and value. They are useful for tracing identifiers, content-type hints or routing context that should not be confused with the main business payload. Header values are bytes and require an agreed interpretation.
For example, a producer can attach a correlation ID so logs from successive services can be linked while leaving the payment schema unchanged. Headers can contain repeated keys, so consumers should not automatically assume they form a unique-key map. They also are not an authorization boundary: a caller able to produce a record may be able to supply misleading header values. Avoid putting secrets in headers, and verify that intermediary applications preserve any metadata required by downstream observability or processing.
34. How do batch.size and linger.ms affect producers?
batch.size influences how much data a producer batches per partition, while linger.ms allows a short wait for more records before sending an otherwise ready batch. Batching can improve throughput by sharing request and compression overhead, but extra waiting can increase latency at low traffic rates.
For example, a high-volume telemetry producer may benefit from fuller batches, whereas an interactive workflow may prioritize tighter tail latency. Measure actual batch sizes and request latency rather than assuming a larger limit always helps; traffic scattered across many partitions can produce many small batches. Kafka 4.0 changed the Java producer's default linger.ms from 0 to 5 milliseconds, so copied tuning advice should state its client version. Broker backpressure and buffering can add delays beyond the configured linger.
35. Why can compression improve Kafka performance?
Compression reduces the bytes transferred and stored, often improving throughput when network or disk bandwidth is the bottleneck. Kafka producers compress batches, so similar records grouped together can compress better than tiny isolated writes. The trade-off is CPU time for compression and decompression.
For example, repetitive JSON telemetry may compress well, while already-compressed binary payloads may offer little additional reduction. Compare supported codecs using representative event sizes, batch fullness and hardware rather than selecting solely from a generic benchmark. Monitor producer CPU, broker resources, end-to-end latency and actual compression ratio. Topic-level compression policy can also influence broker work, so ensure producer and broker settings are understood together. Compression does not replace sensible event sizing or eliminate the replication cost of large volumes.
36. Why can producer retries create duplicates?
A producer may not know whether a timed-out request was stored before its response was lost. Retrying that uncertain write can append it again unless the protocol's idempotent producer behavior deduplicates the retry. This is a transport ambiguity, not necessarily a bug in the broker.
For example, the broker stores an invoice event but the acknowledgement never reaches the client. Idempotence helps with supported retries by that producer, yet a business application restarting and independently submitting the same invoice event again is a different problem. Include a stable event or business operation identifier when downstream deduplication is required. Do not interpret a delivery timeout as proof that nothing was written, and do not claim producer idempotence makes an external payment or database update exactly once.
37. How should you choose a topic's partition count?
Choose partition count from expected throughput, desired consumer parallelism, key distribution and operational overhead, then validate with realistic load. There is no universally correct number per topic or per broker. Partition count also becomes part of a keyed routing strategy, so later changes deserve care.
For example, twelve partitions may allow twelve conventional group members to process independently, but one dominant customer key can still saturate a single partition. Adding partitions may change the key-to-partition mapping for new records and complicate per-key continuity during migration. Too many partitions increase metadata, file and recovery work even when traffic is low. Explain the measured bottleneck before recommending an increase, and distinguish adding partitions from increasing replication factor or moving replicas across brokers.
38. How do consumer fetch settings differ from max.poll.records?
Fetch settings control how the client requests and buffers data from brokers, while max.poll.records limits how many cached records a poll() call returns to the application. Reducing the latter does not necessarily reduce every network response or the client's underlying fetch cache.
For example, lowering max.poll.records from a large value can help a slow application finish each returned batch before its poll deadline, but it may not solve memory pressure caused by large fetched batches. Investigate fetch.max.bytes, max.partition.fetch.bytes and actual record sizes together. Some byte limits allow an oversized first record batch so consumption can make progress, so they should not be described as absolute process-memory caps. Bound application queues as well as adjusting client configuration.
39. How do client.id and group.id differ?
client.id labels a client for observability and can participate in quota identification, while group.id identifies a consumer group and its coordinated progress. Changing a client label is not equivalent to creating an independent consumer group.
For example, instances can use client IDs billing-worker-a and billing-worker-b while sharing group ID billing-v1. Their metrics are distinguishable, but they divide the group's assigned partitions. If both instead use different group IDs, they independently read the stream and can trigger duplicate business work unless that is intentional. Neither string is a secret or proof of identity; authentication and authorization remain separate concerns. Use stable, meaningful naming conventions, but avoid embedding sensitive customer data in identifiers that appear in logs and metrics.
40. When is Kafka a poor fit for a workload?
Kafka is a poor fit when its partitioned-log model adds complexity without serving the workload's requirements. A small synchronous request-response application, arbitrary record-by-record querying, or work requiring broker-managed per-message priority may be better served by a simpler database, API or a messaging system designed for those semantics.
For example, placing a user-profile lookup on Kafka does not automatically create an efficient query service; someone still has to build and operate the materialized view and response path. Conversely, durable replay, multiple independent consumers and sustained event throughput are strong reasons to consider it. A good interview answer compares concrete requirements, failure handling and team operating capacity rather than declaring Kafka either mandatory for scale or unsuitable merely because the initial traffic is small.
Kafka Interview Questions and Answers for Intermediate
These answers focus on implementing correct clients and integrations. Configuration fragments are scoped examples, not complete production configurations; validate security, dependencies, and failure handling for the deployment.
41. How would you diagnose producer buffer exhaustion?
Compare the application's submission rate with the producer's delivery rate and inspect buffer-wait metrics, request latency, and errors. buffer.memory funds queued records but is not a hard cap on all producer memory. When delivery cannot keep up, increasing this buffer can postpone failure while increasing queueing rather than fixing the cause.
For example, a stalled broker connection may let an HTTP service enqueue events faster than Kafka can accept them. Bound upstream concurrency and decide whether callers should wait, fail, or persist publication intent elsewhere. Check whether slow metadata discovery or unavailable leaders explain the backlog before buying more memory. Keep a finite admission policy: accepting unlimited requests transfers an observable Kafka slowdown into an application outage. Retest backlog drain after the underlying delivery problem is repaired.
42. Why should producer callbacks avoid slow application work?
A producer callback should record the outcome quickly and hand expensive work to a separate bounded execution path. Callbacks generally run on the producer's I/O thread; blocking that thread with a slow database call can delay unrelated sends and make a healthy broker appear slow.
For example, writing a detailed audit document synchronously inside every callback couples Kafka delivery to the audit database's tail latency. Capture the record identity and outcome, enqueue an audit task safely, and define what happens if that queue is full. Moving work to another executor does not remove the need for error handling or preserve callback completion order automatically. Also distinguish callback success from completion of the follow-on audit operation. Instrument both paths so operators can tell whether delivery or post-delivery application work is failing.
43. How do max.block.ms, request.timeout.ms, and delivery.timeout.ms differ?
max.block.ms bounds certain blocking producer API operations, such as waiting for metadata or buffer space during send(). request.timeout.ms bounds waiting for a broker response to an individual request. delivery.timeout.ms limits the overall time allowed to report delivery success or failure after send() returns, including batching and retries.
Suppose a producer can enqueue immediately but the leader is unavailable. Increasing max.block.ms will not provide the intended extra retry budget; delivery-related settings govern that stage. Conversely, an exhausted buffer can block the caller before a record is accepted into the asynchronous pipeline. Keep delivery.timeout.ms at least as large as request.timeout.ms + linger.ms. Explain which latency budget the application is enforcing and surface failures to the caller. An HTTP request timeout and a Kafka delivery timeout are separate clocks, so the application must handle a request ending while a send remains in flight.
44. Which settings must remain compatible with Kafka producer idempotence?
Idempotence requires compatible acknowledgement, retry, and in-flight request settings: acks=all, retries greater than zero, and max.in.flight.requests.per.connection no greater than five. The Java producer enables idempotence by default when no conflicting configuration disables it; explicitly requesting it with incompatible values produces a configuration error rather than a valid stronger guarantee.
A useful configuration fragment is:
This protects the producer's retry path from adding duplicate log entries for the same sequenced batch. It does not recognize two independent application calls as the same business event. If a caller submits invoice 123 twice, the broker may correctly store both records. Include a business event identifier and downstream deduplication where that distinction matters. Idempotence also does not replace sufficient replication, appropriate min.insync.replicas, or handling of terminal send errors.
45. When can producer retries change record order within a partition?
With idempotence disabled and multiple requests in flight, a failed earlier batch can be retried after a later batch has already succeeded. That can reverse application send order within the partition. Compatible idempotent producer settings preserve ordering across retries; simply enabling a large retry count is not enough.
Imagine batches A and B target partition 2. A fails transiently, B is accepted, and the producer then retries A. Without the sequencing protection, the log can contain B before A. Setting the in-flight limit to one is a possible non-idempotent ordering safeguard, but it can reduce throughput and does not itself deduplicate retries. First define the relevant order: Kafka's partition log order is not a universal ordering of concurrent callers or multiple producers. If business order matters, establish the key, source sequencing, and concurrency rules as well as the producer configuration.
46. What should an application do when a producer send has an ambiguous outcome?
An application should treat an ambiguous send failure as an uncertain outcome, not proof that the record is absent. The broker might have appended a record before the client lost the response. Blindly sending the same business event again through a new application-level request can create a duplicate even when normal producer retries are idempotent.
For example, persist an event identifier with an order update and make downstream processing reject or merge repeated identifiers. Record enough diagnostic context to distinguish validation failures, authorization failures, transient delivery failures, and uncertainty after a connection loss. Use the producer's completion callback or returned future rather than assuming send() means durable success. A retry policy should define which errors are retryable and what the business deduplication boundary is. Avoid promising that looking at a single consumer immediately will resolve uncertainty, because visibility, transactions, and consumer progress can delay observation.
47. What is the lifecycle of a transactional Kafka producer?
Configure a stable, unique transactional.id for a logical producer instance, initialize transactions, begin a transaction, send its records, and commit only when the transaction's work is ready. Abort a transaction when recoverable application processing fails; fatal fencing errors require stopping that producer rather than continuing with a compromised identity.
The following Java sequence illustrates the successful path, not a complete exception-handling implementation:
Choose identifiers so that an intended replacement can fence its predecessor without accidentally fencing an unrelated live instance. Keep transaction duration bounded and configure downstream consumers appropriately. A successful transaction commit establishes atomic visibility for participating Kafka writes to read_committed consumers; it is not an atomic commit of an arbitrary database update or HTTP call performed between these methods. Production code must classify exceptions and close failed producer instances safely.
48. Why can a read_committed consumer stop before the partition's latest records?
A read_committed consumer reads only up to the last stable offset, which is constrained by the earliest open transaction in that partition. It filters aborted transactional records and does not expose records beyond that stability boundary until the transaction is resolved. Therefore, an open transaction can delay visibility even when newer records exist in the log.
Consider a transaction that writes at offset 100 and remains open while other producers append later records. A dashboard comparing the consumer's position with the physical log end may show apparent backlog that the consumer cannot yet read. Investigate transaction duration and producer health before increasing the consumer fleet. read_committed still delivers non-transactional records when they fall within the readable range; it does not turn all producers into transactional producers. Monitor visible progress separately from raw log growth when diagnosing these stalls.
49. How can consumed offsets and produced records be committed atomically?
A consume-transform-produce application can include its output records and consumed offsets in one Kafka producer transaction. Disable ordinary consumer auto-commit, begin the transaction, produce the results, call sendOffsetsToTransaction with the next offsets and current consumer group metadata, then commit the transaction. Downstream consumers must use read_committed to observe the intended isolation.
For example, after processing input offset 57 successfully, the transaction carries offset 58 as that partition's restart point. If the transaction aborts, its output remains invisible to committed readers and the group has not advanced through that input transaction. The application must also handle ownership changes, exceptions, and reprocessing correctly; the API sequence is not a substitute for lifecycle management. This boundary covers Kafka records and Kafka group offsets, not a payment API invoked during transformation. Kafka Streams can manage this pattern for supported topologies instead of requiring custom transaction coordination.
50. Why do Kafka transactions not automatically make database writes exactly once?
Kafka transactions coordinate Kafka writes and participating Kafka consumer offsets; an ordinary external database transaction is outside that atomic boundary. If a consumer commits a database update and crashes before its Kafka offset advances, the record can be delivered again. Reversing the order can instead skip an update after a crash.
For an inventory consumer, one practical design stores the event identifier and inventory change in the same database transaction, with a unique constraint or equivalent idempotent operation preventing a repeated event from applying twice. Another design stores the consumed position alongside the database result and manages recovery from that store. These approaches require careful concurrency and ownership handling; merely setting isolation.level=read_committed does not implement them. Describe the actual guarantee—such as at-least-once delivery with idempotent database effects—and test failures between the two systems rather than attaching an unqualified exactly-once label.
51. When should a consumer use synchronous versus asynchronous offset commits?
Use synchronous commits when the application needs an immediate success or failure result before proceeding; use asynchronous commits when reducing blocking in the processing loop is more important and failures are handled deliberately. Neither method makes unfinished work safe to acknowledge. The offset map must represent completed processing, not merely fetched records.
A common design uses asynchronous commits during normal operation and a final synchronous commit during an orderly handoff or shutdown, subject to current partition ownership. Avoid manually retrying an old asynchronous offset snapshot after a newer commit has succeeded: doing so can move the stored restart point backward and increase replay. In an interview, explain what happens when a commit fails because the consumer no longer owns the partition. Reprocessing may be the correct outcome. Do not respond by forcing an offset update without checking ownership and completed work.
52. Which offset should a consumer commit after processing a batch?
Commit the offset of the next record the application should read, separately for each partition. If the last safely completed record in a partition has offset 24, commit 25. When processing a whole partition batch synchronously, the last record's offset plus one is suitable; it is not safe when work completes out of order and earlier records remain unfinished.
For a concrete example, offsets 20, 21, and 22 are dispatched to workers. If 22 completes first but 21 has not, committing 23 would risk losing unfinished work after a restart. Track the contiguous completed frontier for each partition and advance only through it. Offset gaps caused by compaction or filtering do not invalidate the next-position concept; do not assume every integer corresponds to a delivered application record. Rebalance callbacks and shutdown handling must use the same completion accounting as the regular commit path.
53. How should a consumer shut down without acknowledging unfinished work?
Signal shutdown to the consumer's owning thread, interrupt a blocking operation with the supported wakeup() mechanism when needed, and perform bounded cleanup on that owner. Stop admitting work, establish the safely completed per-partition positions, and commit only progress that remains eligible under current ownership before closing the consumer.
For example, a deployment termination deadline may leave five database operations unfinished. Committing the last fetched position merely to exit cleanly could skip those operations after restart. Allow replay instead, relying on the application's idempotent effect handling. Do not wait indefinitely for a hung dependency or operate the consumer concurrently from the termination thread. Track the difference between a deliberate shutdown interrupt and an unexpected processing exception, and make the deployment grace period consistent with the bounded drain policy.
54. What should a rebalance listener do with in-flight records?
A rebalance listener should coordinate partition ownership with processing and offset management. Before voluntarily releasing revoked partitions, stop dispatching new work for them, establish which records completed safely, and commit only eligible completed positions when ownership and protocol conditions permit. Do not blindly commit the consumer's current position if workers are still processing its fetched records.
For example, keep a generation or ownership token with each partition's tasks. After reassignment, discard stale completion notifications rather than allowing an old worker to advance the new owner's progress. Handle lost partitions differently from an orderly revocation: by the time onPartitionsLost runs, another member may already own them, so committing on their behalf is unsafe. Keep callbacks bounded to avoid making the rebalance itself hang. Where side effects cannot be canceled, use idempotent handling because a new owner may replay the same records while old work finishes.
55. How do eager and cooperative rebalancing differ under the classic protocol?
An eager rebalance revokes all current assignments before the group establishes its new assignment. Cooperative rebalancing can revoke only the partitions that need to move, allowing consumers to retain other work while the transfer completes. This can reduce disruption, but the application still needs correct revocation handling and an assignor migration plan.
Under the classic protocol, a cooperative assignor such as CooperativeStickyAssignor is not interchangeable with Kafka 4.x's separate consumer group protocol. For example, a rolling deployment using cooperative assignment may keep many partitions processing while a few move to the new instances. That does not mean every rebalance is free or instantaneous. Mixed client settings and supported assignor lists influence migration safety. Discuss the precise protocol and assignor in use rather than saying that a recent broker version automatically makes every consumer cooperative. Validate callbacks and group behavior during rolling changes.
56. What changes when a Kafka 4.1 consumer uses group.protocol=consumer?
The newer consumer group protocol moves assignment coordination to the broker and supports incremental group reconciliation. A Kafka 4.1 consumer opts in with group.protocol=consumer; classic-protocol assumptions about client-side assignment and heartbeat configuration must not be carried over unchanged. The client default remains classic in the documented 4.1 configuration.
Under the consumer protocol, the broker controls heartbeat and session timing through its consumer-group settings, and a server-side assignor is used. For example, changing the classic client's heartbeat.interval.ms is not the way to tune the new protocol. Inventory client compatibility, subscription behavior, and deployment requirements before migrating a production group. Test a representative rolling deployment and failure recovery, not just a happy-path join. Distinguish this protocol change from enabling a cooperative assignor in a classic group: the operational controls and coordination responsibilities are different.
57. When is static consumer membership useful, and what can go wrong?
Static membership gives a consumer a stable group.instance.id, allowing the coordinator to recognize the same logical member across brief interruptions. It can reduce unnecessary partition movement during controlled restarts, particularly when restoring local state is expensive. Each live member must have a unique stable identity; copying one identifier into every replica can cause fencing rather than resilience.
For example, a stateful deployment might derive the identifier from a persistent instance name rather than a random process ID. The trade-off is slower reassignment after a genuinely dead member when the group waits for the relevant timeout. Static membership does not permit a stalled application to stop polling indefinitely or eliminate the need to manage max.poll.interval.ms. Choose timeout values against recovery requirements, and test both short restarts and permanent node loss. Optimize for reduced disruption without silently accepting an unacceptable outage window.
58. How should a multithreaded application use KafkaConsumer safely?
Keep normal KafkaConsumer operations on one owning thread because the Java consumer is not thread-safe. That thread can poll, manage assignments, pause partitions, and commit offsets while worker threads perform bounded application processing. Use a thread-safe handoff for worker results; wakeup() is the special mechanism commonly used to interrupt the owner's blocking operation during shutdown.
The difficult part is preserving per-partition processing order and commit correctness, not simply creating an executor. A practical design allows one active task chain per partition and tracks a contiguous completion frontier. When a partition is revoked, invalidate its ownership token and stop scheduling its work. Multiple independent consumers are often simpler if the partition count and resource budget support them. More threads cannot increase group-level consumption parallelism beyond available partition ownership, and uncontrolled concurrent side effects can violate business ordering even though Kafka delivered records in order.
59. How do pause and resume help with consumer backpressure?
pause() temporarily stops fetching from selected assigned partitions without giving up their assignment, and resume() makes them fetchable again. They help bound in-flight work when a downstream service is slower than Kafka. The consumer must continue polling and managing its lifecycle; pausing partitions is not permission to ignore poll timing or rebalances.
For example, pause a partition when its worker queue reaches 1,000 records and resume it below a lower watermark such as 300. The two thresholds prevent rapid oscillation. Keep queue limits based on bytes or processing cost as well as record count, because 1,000 tiny events and 1,000 large documents have different memory footprints. Coordinate paused state with assignment changes, and avoid assuming it is a durable setting across rebalances. Backpressure shifts where waiting happens; it does not fix an undersized database or an indefinitely failing dependency.
60. How would you distinguish consumer lag caused by capacity from lag caused by a stall?
Compare the growth of lag with input rate, processing rate, partition-level progress, and application health. A capacity shortage usually shows continued progress at a rate below arrivals. A stall may show one partition or the whole group making no progress despite available resources, often alongside errors, a blocked dependency, repeated rebalances, or an open transaction limiting committed visibility.
For example, if nine partitions advance while one remains fixed, adding consumers may not help a hot key or a poison record on that partition. Examine processing latency, queue depth, poll intervals, commit failures, and downstream response times. Separate current fetch position, committed group position, and actual completed business work: each measures a different boundary. Lag expressed as an offset distance is not an exact count of remaining business events or a time-to-recovery estimate. Calculate recovery time from measured net drain rate and account for continuing arrivals.
61. When is manual partition assignment appropriate instead of subscribe?
Use manual assignment when the application deliberately owns partition selection and does not want consumer-group subscription balancing to decide it. assign() does not arrange automatic ownership transfer among application instances. The application must coordinate any exclusivity it needs and respond to topic or deployment changes itself.
A bounded audit job might assign a specific partition and seek to a recorded start position, avoiding changes to a production group's subscription. If two such jobs use the same committed-offset identity, however, their progress can interfere even though assignment was manual. Prefer deliberate identities and explicit start and end positions for independent work. Do not mix subscription and manual-assignment models casually. This is a control-plane design choice, not a shortcut that removes offset bookkeeping, retention limits, or the need to handle broker failures.
62. How can a consumer replay records from a timestamp?
Use a timestamp lookup such as offsetsForTimes to find a starting offset for each relevant partition, then seek each partition to its returned position under a controlled replay plan. The lookup concerns Kafka record timestamps, which may reflect producer event time or broker append time depending on topic configuration. It is not a query over an arbitrary timestamp field inside the value.
For example, a repair job can use a dedicated group so that it does not disturb the live application's committed progress. Handle partitions with no matching offset and decide whether to skip them or start elsewhere. Establish an end boundary if the job should process a finite historical interval, because a consumer otherwise continues into new data. Validate duplicate side effects and available retention before starting. Timestamp lookup narrows the starting point; application filtering may still be needed to enforce the exact business-time interval.
63. How should a consumer handle a poison record without hiding data loss?
Define an explicit policy for records that repeatedly fail, distinguishing malformed serialization from a valid event that violates a business rule or encounters a temporary dependency failure. Retry transient errors within a bounded policy; quarantine irrecoverable records with diagnostic context when the business permits continued processing. Skipping silently is not a recovery strategy.
For example, a quarantine envelope can contain the source topic, partition, offset, event identifier, error category, and original bytes subject to privacy controls. Decide when the source offset may advance and how a failed quarantine write affects that decision. A malformed record can fail before a normal application object is available, so the deserializer or raw-byte handling strategy matters. Preserve ordering requirements: sending one failed debit aside while applying later account events may be unacceptable. Monitor quarantine volume, define ownership for repair, and test replay so the queue does not become permanent storage for lost work.
64. How should segment rolling influence a retention investigation?
Inspect segment boundaries as well as retention thresholds because Kafka's delete cleanup operates on segments rather than deleting each record on its birthday. Segment size and time settings affect when the active segment rolls and becomes eligible for later cleanup. Retention itself can also trigger rolling; cleanup checks and physical file deletion add further timing considerations.
For a low-volume topic, an operator might see old data and incorrectly conclude that the retention configuration was ignored. Inspect the effective topic settings, segment timestamps, and cleanup state before changing policy. Very aggressive rolling can create many small files and indexes, so it has an operational cost. Conversely, estimating storage as an exact per-record expiration window understates possible headroom needs. Verify actual reclaimed bytes after a controlled policy change instead of promising immediate deletion from a configuration update.
65. What does cleanup.policy=compact,delete mean?
Combining compact and delete enables both key-based compaction and time- or size-based segment deletion. Compaction can remove superseded values, while deletion can remove old segments even when they contain the latest remaining value for a key. The result is not an indefinitely retained complete snapshot of all keys that ever existed.
For example, a topic configured to retain only seven days may eventually lose an inactive account's latest state, even if no newer update supersedes it. A consumer rebuilding a full account directory must therefore obtain a baseline elsewhere or use a retention design that preserves the required state. Explain whether the topic is a bounded cache feed, a durable change history, or a state reconstruction source. Those purposes demand different policies. Monitor cleaner progress and storage usage separately: compaction eligibility and retention deletion solve related but distinct problems.
66. Why can a compacted topic accumulate a large dirty log?
Compaction requires both eligible data and sufficient cleaner capacity. Inspect segment eligibility, dirty-ratio thresholds, compaction lag settings, cleaner progress, and disk pressure before assuming that key repetition should instantly reclaim space. A workload with mostly unique keys may have little redundant data to remove even when cleaning works correctly.
For example, an application accidentally changing its key from customer ID to a unique event ID can convert a useful state feed into an ever-growing collection of distinct keys. Raising cleaner throughput would not restore the intended key contract. Conversely, a correct high-update workload may genuinely outrun available cleaning resources. Compare logical key cardinality, update rate, and cleaned-byte rates. Preserve enough temporary disk space for cleaning work and avoid lowering retention blindly when full-state reconstruction is required.
67. How should teams manage event schema evolution in Kafka?
Treat the serialized event format as a contract shared by producers and consumers, with compatibility rules, versioned tests, and a rollout plan. Kafka brokers store bytes and do not automatically enforce business schema compatibility. A schema registry may provide useful validation and discovery, but vendor products such as Confluent Schema Registry are not a built-in Apache Kafka core service.
For example, adding an optional field can be safer than changing an existing field from a numeric amount to a formatted string, but the actual result depends on the serialization format and reader behavior. Test both old readers with new messages and new readers with retained old messages. Replay makes backward readability important long after deployment. Keep key schemas particularly stable because changing serialized key bytes can alter partition placement and compaction identity. Publish semantic changes explicitly rather than assuming an unchanged field name means an unchanged contract.
68. How do Kafka Connect connectors, tasks, and workers differ?
A connector defines and manages an integration, tasks perform its data movement, and workers are the runtime processes that execute those components. In distributed mode, Connect coordinates task placement across workers and stores coordination-related state in Kafka internal topics. Increasing worker count provides execution capacity and fault tolerance, but it does not guarantee that a particular connector can use more parallel tasks.
For example, a source reading one inherently sequential external feed may remain effectively single-task even if tasks.max is large. A sink may also be limited by source partitions or destination throughput. Ask what the connector implementation can split, how tasks resume, and whether required plugins are present on every eligible worker. Separate connector configuration failures from individual task failures when diagnosing status. Connect is an integration runtime, not a promise that any installed connector has identical scaling, offset, or delivery semantics.
69. What is the difference between Connect converters and single message transforms?
Converters translate between Kafka bytes and Connect's internal data representation, including schema information where supported. Single message transforms, or SMTs, make lightweight changes to individual records as they move through the connector pipeline. They solve different problems: a converter establishes serialization, while a transform can rename a field, extract a key, or route a record.
For example, an SMT might copy an order ID into the key so a sink can perform keyed updates. That does not make an incompatible value converter understand arbitrary bytes already in the topic. Order the transforms deliberately and verify the resulting key, value, schema, and destination topic. Keep complex stateful joins and aggregation out of SMT chains; a stream-processing application is usually a clearer place for that logic. Test nulls, tombstones, and missing fields, because a transform that works on ordinary inserts may fail on deletion events.
70. What are the limits of Kafka Connect error tolerance and dead-letter queues?
Connect error handling can tolerate selected record-processing failures and, for supported sink-side paths, route problematic records to a dead-letter topic. It does not guarantee that every connector exception, external-system outage, or source-side failure will be captured there. The connector implementation and the stage where the error occurs determine the available behavior.
For example, a malformed sink record may be quarantinable, while a database connection failure may stop the task and require recovery rather than record skipping. Enabling broad tolerance without monitoring can transform an obvious outage into silent incomplete data. Include enough source context for investigation, secure the dead-letter topic, and avoid leaking sensitive payloads through error logs. Define who repairs records and how replay avoids duplicate destination changes. Validate behavior with the actual connector rather than assuming a generic Connect setting covers all possible failure modes.
71. How do source and sink connectors track progress differently?
A source connector tracks positions in its external system, such as a file location or database change-stream position, using source partition and offset information supplied by the connector. A sink consumes Kafka partitions and coordinates Kafka consumer progress with writes to its destination. These are different coordinate systems even though both are commonly called offsets.
For example, a source's database log position cannot generally be substituted for a Kafka topic offset. During recovery, inspect the connector's documented offset representation and the availability of the underlying external history. For a sink, verify when destination writes are considered complete relative to offset commits. A crash between those steps can require replay, and safe replay depends on destination semantics. Source exactly-once support is conditional on distributed-worker configuration and connector capabilities; sink guarantees likewise depend on the connector and external system. Do not infer end-to-end exactly-once behavior merely because Connect manages offsets.
72. How do KStream and KTable represent data differently?
A KStream represents a sequence of individual events, while a KTable represents keyed updates to a changing table. Two records for the same key are two events in a stream; in a table, the later value updates the row for that key. A null table value acts as a deletion rather than an ordinary non-null business value.
For example, purchase events belong naturally in a stream when every purchase contributes to revenue. A customer profile feed belongs naturally in a table when the latest address should replace the prior address. Choosing the wrong abstraction can double-count updates or discard meaningful event history. The distinction also changes joins: enriching a stream with table state is not the same operation as joining two event streams within a time window. Decide whether the input means “something happened” or “this key's state is now this” before selecting the API.
73. Why does a Kafka Streams topology sometimes need repartitioning?
Repartitioning redistributes records by the key required for a subsequent stateful operation. If an earlier transformation changes the key, the original partition placement may no longer ensure that all records for a group reach the same task. A repartition topic provides the shuffle needed for correct aggregation or compatible joins.
For example, an order stream initially keyed by order ID may be regrouped by merchant ID to calculate merchant totals. The topology must bring each merchant's events together even if they originally arrived on different partitions. This adds network traffic, broker storage, serialization work, and recovery dependencies. Inspect the built topology rather than assuming every key-changing operator immediately causes a shuffle; DSL optimizations and the following operations matter. Explicitly name important internal resources where appropriate and check key serdes. Avoid unnecessary key changes when a stable upstream partitioning contract already supports the intended computation.
74. How do event-time windows and grace periods affect late records?
Event-time windows group records by their timestamps rather than the wall-clock moment at which the application processes them. A grace period determines how much out-of-order arrival a windowed operation permits after a window ends, judged against stream-time progress. It is not simply a timer that starts when a worker first sees a record.
For example, a five-minute sales window may accept delayed receipts within its configured grace interval, allowing mobile devices to reconnect without immediately losing their contribution. A longer grace period improves tolerance but retains more state and can delay final results. Records beyond the allowed boundary may be dropped by the operation, so monitor late-record metrics and choose a business policy for corrections. Window type, timestamp extraction, retention, and emission behavior must be specified together. A grace period alone does not guarantee a single final output; suppression or downstream upsert handling may be relevant.
75. How does Kafka Streams recover local state after a failure?
Kafka Streams can rebuild logged state stores from their changelog topics when a task moves or loses local state. Reusable local state and standby replicas can shorten recovery, but recovery still consumes storage bandwidth, network capacity, and broker resources. The exact restoration path depends on the store and topology, so not every store has an identical changelog arrangement.
For example, a large aggregation may take much longer to restore on a fresh machine than to restart on the same persistent disk. Plan for restoration throughput and the input backlog accumulated during recovery, not just steady-state processing. Ensure internal topic replication and retention settings support the intended resilience. A local state directory is not by itself a durable backup strategy, and deleting it can turn a quick restart into a full rebuild. Measure restore time under realistic state size and concurrent failures before choosing an availability target.
76. What does processing.guarantee=exactly_once_v2 provide in Kafka Streams?
processing.guarantee=exactly_once_v2 enables Kafka Streams' transactional processing mode so that input-offset progress, Kafka output records, and state updates are coordinated for its Kafka processing boundary. It addresses failures that would otherwise expose duplicate or inconsistent processing results within that boundary. Downstream readers need appropriate committed-read behavior to avoid observing aborted transactional writes.
For example, a topology that aggregates Kafka events and writes totals to another Kafka topic can recover without exposing a partially committed batch as a successful result. That does not make an HTTP request inside a processor execute only once. Keep external effects idempotent or use a separate integration design whose guarantees are explicit. Transactions also have resource and latency costs, so benchmark them under representative failure and load conditions. Select the mode deliberately, verify broker compatibility and internal-topic durability, and avoid calling the entire business workflow exactly once when only its Kafka segment is covered.
77. How do TLS, SASL, and ACLs address different Kafka security needs?
TLS protects data in transit and can authenticate peers through certificates. SASL provides authentication mechanisms for identifying clients. ACLs authorize which identified principals may perform operations on Kafka resources. These are complementary controls: encryption alone does not establish least-privilege access, and authenticating a user does not decide which topics that user may read.
For example, a service can connect using SASL_SSL, authenticate as its own principal, and receive only the topic and group permissions it needs. Validate certificates and hostnames rather than disabling checks to make a connection succeed. Protect inter-broker and controller communication as part of the deployment's threat model, not only public client listeners. Store secrets outside source code and plan rotation. Finally, distinguish transport security from data governance: encrypting a connection does not prevent an authorized application from logging sensitive event values or copying them to an insecure destination.
78. How would you apply least privilege to a Kafka application?
Give each application an identifiable principal and grant only the operations it needs on its topics, consumer groups, and any transactional resources. Separate administration from ordinary produce-and-consume access, and scope resource patterns carefully. A broad wildcard grant may solve a deployment problem while exposing unrelated data and allowing unintended resource changes.
For example, an invoice consumer should not automatically receive write access to payroll topics or permission to alter cluster configuration. A transactional producer or Streams application may need additional permissions for its transaction identity and internal resources; determine those from the actual topology and authorization errors rather than granting cluster-wide privileges preemptively. Test both allowed and denied operations in a non-production environment. Maintain an owner and purpose for each principal, remove unused grants, and coordinate credential rotation with deployment procedures. Authorization reviews should include internal topics and replay jobs, not only the primary application's input topic.
79. Why can a large Kafka record fail even after increasing max.request.size?
A large record passes through several independent limits: producer request limits, broker or topic record-batch limits, consumer fetch controls, and practical memory constraints. Raising only max.request.size does not guarantee the broker will accept the resulting batch. Compression also makes it important to distinguish serialized record size, compressed batch size, and total request size.
For example, a 12 MB document may fit the producer's new setting but still exceed the topic's allowed batch size. Review producer, topic, broker, replication, and consumer settings as a coordinated design rather than increasing values until one test passes. Consumer fetch limits have progress exceptions for an oversized first batch, so they should not be described as universal hard caps on every returned record. Consider storing large immutable payloads externally and publishing a reference with integrity metadata. That alternative introduces its own access, lifecycle, and atomicity concerns, but often produces more predictable Kafka memory and latency behavior.
80. What happens if you change a producer's key serialization or partition count?
Changing serialized key bytes or increasing the topic's partition count can change where future keyed records are written. Existing records are not automatically redistributed. As a result, the same logical business key can have old records in one partition and new records in another, weakening a consumer's assumption that reading one partition preserves that key's entire history in order.
For example, switching an account key from raw UTF-8 text to a schema-encoded representation may alter its hash even if the displayed account ID is unchanged. Plan the migration with an explicit ordering boundary, drain-and-cutover procedure, or versioned topic where the application requires strict continuity. Compacted topics deserve special care because byte-level key identity and partition placement underpin state reconstruction. Do not treat adding partitions as a harmless capacity-only operation. Test representative keys and document the partitioner contract, while avoiding dependence on partition numbers as permanent business identifiers.
Kafka Interview Questions and Answers for Experienced
These answers prioritize evidence and failure boundaries over universal recipes. A strong response identifies the affected partitions or tasks, protects recoverable state, and explains how the proposed change will be verified.
81. How would you reason about durability when a three-replica partition loses two replicas?
Start with the surviving replica's log and eligibility, not just the configured replication factor. With replication factor three, min.insync.replicas=2, and producers using acks=all, ordinary writes are rejected when the required in-sync replica count cannot be met. That deliberately trades availability for a stronger replication requirement; lowering the minimum during the incident changes the guarantee rather than repairing replication.
Suppose A and B acknowledged a record while C was behind. If only C survives, making C leader through an unsafe recovery path can discard acknowledged data. If A survives, previously committed records may remain readable even though new writes cannot satisfy the minimum. Eligible leader replicas are enabled by default on new Kafka 4.1 clusters; verify the feature state on upgraded clusters. Do not equate every replica outside the current ISR with the same recovery status. Verify actual leader eligibility, replica progress, and failure domains before choosing recovery actions.
82. How does transactional fencing prevent a zombie producer from continuing?
A transactional identity lets Kafka distinguish a current producer from an obsolete instance using that same identity. When a replacement initializes appropriately, an older producer can be fenced and must stop using the invalidated instance. This protects Kafka transactional ownership; it does not kill the old process or cancel an external HTTP operation it already started.
Suppose deployment recovery starts a replacement while the old pod is merely isolated rather than dead. A stable identity can prevent both from successfully continuing the same logical transactional role. Accidentally assigning that identity to two unrelated healthy workers creates disruption instead. Review the mapping from logical worker to transactional identity, replacement behavior, and fatal-exception handling together. Test the zombie case explicitly, including external effects that require their own ownership or idempotency controls.
83. When is an unclean leader election an unacceptable recovery choice?
It is unacceptable when restoring availability by electing a replica that can lack committed records violates the data-loss budget. An unclean election is not simply a faster version of ordinary failover: it can establish a new authoritative history that omits records acknowledged earlier. The business owner must understand that consequence before an operator makes such a choice.
For an audit or settlement stream, waiting for a safe replica to recover may be preferable to serving an incomplete history. A disposable telemetry stream might have a different availability objective. Inspect the topic's election policy, current replica eligibility, and Kafka 4.1's eligible-leader-replica configuration rather than applying an old ISR-only runbook mechanically. Preserve logs and evidence before destructive recovery, document the potential missing interval, and plan reconciliation. A nominal replication factor of three does not authorize assuming any surviving disk contains the same committed history.
84. How should replica placement change when brokers span availability zones?
Replica placement should spread a partition's copies across independent failure domains, and the producer durability policy should remain achievable under the failures the service promises to tolerate. Configure broker rack identities to represent the intended topology and verify the resulting assignments rather than assuming different broker IDs imply independent infrastructure.
Consider three replicas across three zones with a minimum ISR of two. Losing one zone can leave two copies available, provided they were sufficiently caught up and the network and controller quorum also remain healthy. Three replicas on separate brokers in the same zone do not provide that protection. Cross-zone replication adds network cost and latency, so benchmark the actual acknowledgment path. Place controllers thoughtfully as well: preserving partition data without a functioning metadata quorum is not a complete resilience design. Test zone isolation and recovery, not only graceful broker restarts, because correlated failures expose different assumptions.
85. How would you respond to a Kafka broker whose disks are almost full?
First identify which disks and partitions are growing and how much safe headroom remains; avoid deleting log files manually. Check ingestion changes, retention settings, cleanup progress, replica movement, and whether compaction or remote-storage expectations are masking local growth. A full disk can turn a capacity problem into unavailable replicas and a broader durability risk.
The immediate remedy might be reducing nonessential ingestion, adding capacity, or moving selected replicas, but reassignment itself consumes disk and network bandwidth. Calculate destination headroom before starting it. Reducing retention is a data-deletion decision and may break consumer recovery or audit requirements, so it needs the appropriate authorization. Increasing segment turnover can affect cleanup eligibility, but it is not an instant guarantee of reclaimed space. Track the time-to-full estimate throughout the response and verify ISR health after recovery. Keep evidence of the trigger so the capacity alert can be improved.
86. What happens when a KRaft controller quorum loses its majority?
Without a majority, the controller quorum cannot safely commit new metadata decisions. This prevents normal progress for operations such as metadata changes and required leadership transitions. It does not mean every existing producer or consumer connection stops at the same instant: some traffic may continue using established partition leaders, but the cluster cannot reliably respond to subsequent failures or changes.
For a three-controller quorum, losing two controllers is therefore a different incident from losing two ordinary brokers. Restore the original quorum's communication or failed members using a version-appropriate runbook; do not create a new cluster identity to make the process start. Investigate network partitions, disk latency, and process health before declaring metadata lost. A useful readiness check examines quorum progress as well as process liveness. Operationally, separate the data-plane symptoms from the metadata-plane outage so continuing traffic is not mistaken for a healthy cluster.
87. Why might you separate KRaft controller processes from broker processes?
Dedicated controllers isolate metadata management from the CPU, heap, disk, and network pressure generated by storing and serving records. Combined roles can simplify a development setup, but a production deployment must consider correlated restarts and resource contention. A heavily loaded broker should not also jeopardize the availability of the metadata quorum merely because both roles share one process or host.
Size controllers for metadata workload, partition and topic counts, broker events, and metadata-log performance rather than copying broker disk-capacity calculations. Conversely, adding controllers is not a way to increase ordinary partition throughput: that workload belongs to brokers. Choose an odd quorum size that matches the required failure tolerance and supported operational design; more voters also add coordination cost. During maintenance, preserve the necessary controller majority and enough healthy partition replicas independently. Document both constraints because a rolling restart plan that is safe for one role may be unsafe for the other.
88. What should you verify before attempting KRaft metadata recovery?
Verify the cluster identity, controller identities, quorum configuration, surviving metadata logs, and the exact failure mode before touching storage. Kafka's metadata describes topics, assignments, configurations, and other control-plane state; reformatting a failed controller is not equivalent to replacing an empty disposable cache. An incorrect recovery step can destroy evidence or create incompatible state.
Start with read-only diagnostics, for example:
This command requires an accessible deployment and appropriate security settings; it is a diagnostic example, not evidence of a running cluster. Compare the report with controller logs and known topology. If the quorum lacks a majority, the command may not establish everything needed for recovery. Preserve surviving directories and use the documented procedure for the configured static or dynamic quorum. Never improvise by assigning a new cluster ID to existing broker data and expecting Kafka to reconstruct a valid cluster automatically.
89. How would you plan an upgrade from a ZooKeeper-based Kafka 3.x cluster to Kafka 4.1?
Treat migration to KRaft and the Kafka 4.x software upgrade as distinct, verified stages. Kafka 4.0 removed ZooKeeper mode, so a ZooKeeper-based cluster cannot simply have its broker binaries replaced with 4.1. Establish a supported migration path for the exact starting release, migrate while using an appropriate 3.x release, and validate the resulting KRaft cluster before proceeding.
Inventory brokers, controllers, Java runtimes, clients, Connect plugins, Streams applications, security settings, and operational scripts. Rehearse the sequence with representative workloads and failover, not only a successful startup. During the rolling software upgrade, watch replication and request errors before advancing. Finalizing feature or metadata versions can restrict downgrade options, so do not combine that step casually with the first binary rollout. Record explicit pause criteria and a recovery plan for each stage. The interview-quality answer explains why a nominally successful broker restart does not establish application compatibility or rollback safety.
90. What compatibility assumptions should be revisited when adopting Kafka 4.x clients?
Revisit both broker compatibility and application API compatibility. Kafka 4.0 removed old protocol/API support, so the historic slogan that every client works with every broker is unsafe. The upgrade documentation requires brokers to be at least 2.1 before upgrading Java clients to 4.0, and server-side compatibility also excludes sufficiently old clients. Kafka 4.1 deployments should use the published compatibility guidance rather than extrapolating beyond it.
Compile applications against the target client libraries, inspect removed APIs and configuration changes, and validate actual negotiated operations. Include administration tools, Streams, and Connect because they use Kafka clients internally. A successful metadata request does not prove transactional operations, group management, or connector behavior will work. Run a staged upgrade with representative produce, consume, rebalance, and restart scenarios. Keep the selected consumer group protocol explicit: changing a client dependency alone is not a substitute for understanding which protocol and feature set the application will use.
91. How would you evaluate follower fetching for a multi-zone consumer?
Evaluate whether locality benefits justify the additional configuration and consistency expectations. Kafka can serve consumer reads from an appropriate follower when rack-aware selection is configured; ordinary leader fetching should not be assumed to change merely because clients and brokers have rack labels.
For a large analytics group, reducing cross-zone fetch traffic may be valuable, but validate actual broker selection, replication lag, and behavior when the preferred replica becomes unavailable. Keep writes and replication costs separate from consumer egress savings. A nearby replica is not an independent writable copy and does not create regional disaster recovery. Compare end-to-end freshness and failover with the existing leader-fetch path before rollout. Include authorization and network reachability for all possible fetch endpoints, not just the consumer's favored local broker.
92. How would you estimate Kafka storage and network capacity?
Begin with the retained compressed data rate and retention horizon, multiply by replication, and then add explicit headroom for indexes, segment behavior, compaction, recovery, and uneven assignment. Separate ingress, replication traffic, and consumer egress because multiple consumer groups can make outbound traffic much larger than producer input. Use measured compression ratios rather than assuming JSON shrinks by a fixed percentage.
For example, 10 MB/s retained for one day produces approximately 864 GB of logical data using decimal units. At replication factor three, the replicated payload alone is about 2.592 TB before overhead and safety margin. That arithmetic is not a complete disk plan: compaction and deletion happen asynchronously, and reassignment can temporarily increase usage. Model the remaining brokers after a failure, when traffic and replica recovery concentrate on less capacity. Track both bytes and request rates, since many tiny records can hit CPU or request-processing limits before disk bandwidth is exhausted.
93. What would you do when one Kafka partition is much hotter than the others?
Identify whether the imbalance comes from a dominant key, producer partitioning behavior, record-size skew, or an unusual consumer workload before adding infrastructure. More consumers cannot divide a single partition within one ordinary consumer group assignment, and moving the partition changes placement rather than its inherent serial workload. More partitions also do not automatically split an existing hot key.
If one account produces half the events, key salting might distribute load, but it sacrifices simple per-account ordering and requires a downstream merge or aggregation strategy. If order is mandatory, optimize processing or isolate that account into an explicit design with a known throughput limit. Compare per-partition bytes, records, lag, and processing latency rather than cluster averages. Also inspect the broker hosting the leader: a hot partition may be compounded by poor leader placement. Choose mitigation based on the actual bottleneck and document which ordering or consistency property would change.
94. How would you calculate whether a consumer can catch up before retention expires?
Calculate net backlog drain from measured completion capacity minus continuing arrivals, then compare the resulting time with the oldest required records' remaining retention window. If processing capacity does not exceed arrivals, the backlog never drains under those assumptions. Use business work or measured bytes consistently rather than treating every offset difference as one available event.
For example, a backlog of 900,000 comparable work items drains in 3,000 seconds at 500 completed items per second while 200 new items arrive each second. That is about 50 minutes before allowing for retries, skew, and rebalances. If required history expires sooner, scaling may be urgent but must respect available partitions and sink capacity. Recompute during recovery because both arrival rate and service time can change; a one-time optimistic estimate is not a recovery guarantee.
95. Which monitoring signals should drive a Kafka production incident response?
Use a layered set of signals that connects service outcomes to client, broker, replication, storage, and controller health. Start with the application's delivery and processing latency objectives, error rates, and backlog age. Then inspect offline partitions, under-replicated or under-minimum-ISR partitions, ISR churn, request timing, disk headroom, network saturation, and controller quorum progress.
A rising under-replicated count during planned reassignment has a different meaning from the same count accompanied by disk errors and unavailable partitions. Likewise, average request latency can conceal a bad tail affecting one critical tenant. Maintain partition and client identifiers so alerts can be narrowed without scanning every metric manually. JMX metric names and availability should be verified for the chosen Kafka version and role. Alert on actionable conditions with runbook context, not every transient gauge change. Finally, use an end-to-end synthetic workflow where appropriate: healthy process metrics do not prove that a business record reaches its intended consumer.
96. How would you move Kafka replicas without causing an avoidable outage?
Create an explicit reassignment plan, verify destination disk and network capacity, and apply movement in controlled batches with suitable throttling. Moving replicas is real replication work competing with normal traffic, not a metadata-only operation. Preserve enough healthy replicas and controller availability throughout the change, especially if maintenance is occurring simultaneously.
Before execution, record the current assignment and identify any already under-replicated partitions. During movement, watch replication progress, ISR changes, request latency, and destination headroom. A plan that balances partition counts may still leave bytes or traffic badly skewed, so account for partition size and leader load. Verify completion and remove temporary throttles through the supported tooling; forgetting them can impair later replication or throughput. Avoid stacking a broad reassignment, broker upgrade, and retention change into one opaque event. Staging the work makes it possible to attribute regressions and stop before a recoverable load spike becomes a durability problem.
97. How do Kafka quotas help with noisy neighbors, and what do they not solve?
Quotas limit selected resource usage by configured identities, such as users and client IDs, so one workload is less able to monopolize broker bandwidth or request-processing capacity. They are useful guardrails in shared clusters, but they do not create complete isolation of disk usage, partition metadata, controller load, or application-level latency. Resource planning and access controls remain necessary.
For example, limiting a bulk backfill can protect interactive consumers, but an overly restrictive producer quota can also push that application's delivery latency past its deadline. Observe throttle metrics and client behavior to distinguish intentional enforcement from unexplained slowness. Choose stable authenticated identities and deliberate client IDs rather than allowing accidental identity reuse to combine unrelated workloads under one limit. Establish separate retention, topic-creation, and partition-count policies for storage and metadata growth. For workloads with sharply different risk or compliance requirements, separate clusters may be more appropriate than attempting to express every boundary through quotas.
98. How would you rotate Kafka credentials without creating an avoidable outage?
Plan credential rotation as a staged identity and connectivity change, not simply a secret replacement. Inventory all clients, brokers, controllers, Connect workers, and Streams instances that use the affected authentication material. Establish how the selected mechanism reloads credentials and whether a restart or reconnect is required; TLS certificates and SASL mechanisms need different procedures.
Where supported, introduce overlapping trust or a replacement identity, validate allowed and denied operations, roll clients, then revoke the old access only after confirming that stragglers no longer depend on it. A certificate accepted for a new connection does not prove hostname verification or every advertised broker path works. Keep rollback available without restoring unnecessarily broad privileges. Monitor authentication failures during the transition and ensure that backups, replay jobs, and infrequently scheduled clients are included in the inventory.
99. How would you diagnose a client that connects to bootstrap servers but cannot produce?
Inspect the broker addresses returned in metadata and verify that the client can resolve, reach, and authenticate to those advertised endpoints. Bootstrap connectivity only establishes an initial discovery path; the client normally talks directly to the brokers hosting the relevant partition leaders. An incorrect advertised.listeners configuration often explains why a smoke test reaches one address but normal operations fail.
For example, an external client may bootstrap through a reachable endpoint and then receive internal-only hostnames. Check DNS, routing, firewall rules, listener security protocol mappings, TLS hostname verification, and SASL configuration for the selected listener. Differentiate connection failure from authorization failure and from a topic lacking an available leader. Avoid disabling certificate verification as the permanent fix for a hostname mismatch. Validate the complete advertised topology from the application's actual network location, not solely from inside the broker network, where inaccessible external paths may be invisible.
100. Why can a consumer fail to reconstruct state even when its topic uses compaction?
Compaction preserves a key's latest retained state under its cleanup rules; it is not an unlimited history or an unconditional reconstruction guarantee. A consumer can miss deletion information if it remains offline beyond the relevant tombstone retention window, and a topic configured with both compaction and deletion can also lose old segments through time or size retention. Null keys and schema changes introduce additional application concerns.
Suppose a cached customer record is deleted and the tombstone is later cleaned away before a stale consumer resumes. Merely consuming the remaining log may leave that stale cache entry intact. A full rebuild from an empty state and a partial catch-up from an old state are different recovery procedures. Define maximum outage and rebuild durations, align retention settings, and test deletions explicitly. Keep a trustworthy snapshot or source-of-truth recovery path when the business requires reconstruction beyond what the retained Kafka log can support.
101. What consistency and routing concerns arise with Streams Interactive Queries?
Interactive Queries expose application state, but querying a distributed application requires locating the instance that owns the relevant store partition. Kafka Streams supplies state-query and metadata facilities; the application must provide any network service used to forward remote requests. A local lookup is not automatically a cluster-wide database query.
For example, a request for a merchant total may reach an instance that does not host that merchant's active store. Route it using current metadata and handle movement or restoration with bounded retries. Define the freshness contract: a result reflects processed state, not necessarily every event already accepted upstream. Protect the query endpoint independently and avoid implying a globally atomic snapshot across unrelated stores or instances. Test requests during rebalances and restoration, not only while all keys remain on stable owners.
102. When would a GlobalKTable be preferable to a partitioned KTable?
A GlobalKTable keeps a full copy of its source table on each application instance, enabling stream enrichment using a lookup key without the same co-partitioning requirement as a partitioned table join. The trade-off is duplicated storage and ingestion work across instances, making it more suitable for bounded reference datasets than enormous constantly changing tables.
For example, a product-category directory may be small enough to replicate everywhere, whereas a complete customer transaction history is not. Budget startup and restoration time as the directory grows. A full local copy does not mean updates are instantaneously synchronized with every stream record, so define acceptable freshness and test concurrent updates. Choose from data size, update rate, join requirements, and failure behavior rather than assuming that avoiding a repartition makes the design free.
103. How can idle inputs affect ordering in multi-input Streams operations?
A task with data buffered for one input but none for another faces a choice between making progress now and waiting for potentially earlier-timestamped records. max.task.idle.ms controls this waiting behavior. It is distinct from a window grace period: one influences processing order across inputs, while the other governs acceptance of late records for a window.
For example, an enrichment input may briefly trail an order stream because its broker fetch is slower. Processing immediately can produce a different observed ordering from waiting for available earlier data. A larger wait can improve synchronization but raises latency when an input is genuinely quiet. Test bursty and idle traffic, not only evenly paced streams. Specify the tolerated freshness and latency trade-off, and inspect the Kafka 4.1 semantics before copying a value from an older deployment.
104. Why can a Streams aggregation emit fewer updates than input records?
State-store caching can coalesce multiple updates to the same key before forwarding them, so downstream update frequency need not match the number of input events. This is different from discarding the events' contributions to the aggregate. Suppression is a separate tool for controlling when results are emitted, such as waiting for a window to close.
For example, three purchases can change a merchant total from 10 to 15 to 22 while a downstream table observer sees only a later consolidated update. A test that expects one output per purchase may be asserting the wrong contract. If every original event is required for an audit, retain the event stream rather than using aggregate emissions as its substitute. Test the configured cache, commit cadence, and result-emission policy, and distinguish final values from intermediate update visibility.
105. How do standby replicas change a stateful Streams application's recovery trade-offs?
Standby tasks maintain copies of applicable state so a failure can promote a more current local copy instead of rebuilding everything from scratch. This can reduce recovery time for large stateful applications, but it consumes additional instances, disk, network bandwidth, and changelog-reading capacity. It does not make every failover instantaneous or eliminate the need for healthy Kafka internal topics.
For a task with hundreds of gigabytes of state, a warm standby can materially improve the recovery-time objective. However, if the standby is placed in the same failure domain as the active task, the expected protection may disappear during a zone outage. Verify actual task placement, standby progress, and enough remaining capacity to run the promoted workload. Tune the relevant assignment and recovery settings for Kafka 4.1 rather than assuming that setting a standby count alone establishes the desired placement. Test both promotion and the subsequent rebuilding of replacement standby capacity under production-like load.
106. How would you safely deploy a change to a stateful Kafka Streams topology?
First determine whether the change preserves the meaning and compatibility of existing state stores, internal topics, serialization, and application identity. A rolling deployment is not automatically safe simply because both versions compile. Renaming an operation, changing aggregation state format, or modifying repartitioning can alter internal resources and invalidate assumptions held by running tasks.
Inspect the old and new topology descriptions and use stable explicit names where appropriate. For a compatible change, test mixed-version operation and restoration before rollout. For an incompatible change, a new application ID with controlled reprocessing or a planned reset may be safer than sharing old state. Protect downstream systems from replayed outputs and budget enough input retention for the rebuild. Reset tools do not magically undo outputs already written to external systems. Document rollback separately: after new-format state has been written, reverting the binary may not restore the previous application's ability to read it.
107. Why do null values and tombstones require special care in Streams joins?
A null value does not have one universal meaning across every Streams operation. In a table-like changelog, a null value for a key represents deletion; in stream processing and particular joins, null keys or values may be skipped or handled according to the operator's documented semantics. Treating all nulls as ordinary missing fields can therefore produce incorrect state or silently absent join results.
For example, deleting a customer from a table used for enrichment is different from emitting an order whose optional address field is null. The first changes table membership; the second can still be a valid non-null record value. Define serialized payload nullability separately from Kafka record tombstones, and test the exact join type with inserts, updates, deletes, and out-of-order events. Check version-specific join behavior rather than relying on an old code example. Include expected downstream deletion or correction behavior in tests so the application does not retain a stale joined result accidentally.
108. What must be true for Kafka Connect source exactly-once support to be meaningful?
The source connector must support the framework's exactly-once capabilities, the distributed workers must be configured for them, and the source system's offset and replay model must permit the required behavior. Enabling a worker option cannot turn an arbitrary connector into an exactly-once implementation. The framework coordinates source records and source offsets through Kafka transactions and fences obsolete task generations, but connector correctness remains essential.
For a new compatible distributed Connect cluster, the relevant worker setting is:
Existing clusters require the documented staged transition through preparing before all workers use enabled. Also verify transactional authorization and use committed-data consumption downstream. Test crashes around source reads, Kafka writes, task reassignment, and offset persistence. A claim that a database source is exactly-once should explain snapshot and change-log behavior, not just quote a configuration value. Standalone Connect mode does not provide this source exactly-once framework capability.
109. Why does a Kafka Connect sink need destination-specific support for exactly-once effects?
The sink must coordinate its destination writes with progress tracking or otherwise make repeated writes harmless. Kafka can provide committed input records, but it cannot automatically make a database update, file append, or HTTP request atomic with a Kafka consumer offset. Reading with read_committed prevents consumption of aborted Kafka transactions; it does not solve the destination's crash window.
Imagine a sink writes an invoice row successfully and crashes before recording progress. On restart, it may receive that record again. A unique business key and an idempotent upsert can prevent duplicate rows, while an append-only endpoint may need a different mechanism. The connector's documented contract must explain how it handles this interval, concurrent tasks, retries, and destination failures. Validate the actual destination and plugin version, not just the Connect framework version. For irreversible side effects, require explicit reconciliation and deduplication tests rather than accepting an unqualified exactly-once label in a configuration review.
110. Why must Connect internal topics be treated as critical shared state?
Distributed Connect relies on Kafka topics for configuration, source offsets, and status. These have distinct roles and documented partitioning and cleanup requirements; they are not disposable application output. In particular, the configuration topic must have one partition to preserve the expected ordering of configuration state.
For example, deleting a shared offset topic to fix one connector can cause other source connectors to lose their restart positions and replay substantial upstream history. Protect these topics with appropriate replication, compaction, access controls, and capacity monitoring. Separate the internal-topic names of independent Connect clusters deliberately rather than accidentally pointing both at the same shared state. During recovery, preserve the worker identity and topic configuration and verify connector progress. Recreating workers is not equivalent to reconstructing missing internal coordination and offset history.
111. How would you investigate a Connect source that resumes from the wrong position?
Inspect the connector's source partition and offset model, the persisted offset state, its identity, and any recent configuration or deployment changes before resetting anything. Source offsets are connector-defined positions such as a log location or file position; they are not simply Kafka topic offsets. Recreating a connector or changing its source identity can therefore change how it associates stored progress with the upstream system.
For a database change stream, determine whether the upstream log position still exists and whether a snapshot is required. Preserve configuration, status, logs, and existing offsets as evidence. Use supported, version-appropriate offset inspection or alteration procedures, and satisfy connector stop-state requirements before modifications. Blindly deleting the offset topic can affect unrelated connectors sharing the worker cluster and trigger extensive replay. Establish the expected duplication or gap window and verify destination reconciliation afterward. A restart that produces new records is not enough to prove that no historical records were skipped.
112. Why might increasing Connect tasks.max fail to improve throughput?
tasks.max is an upper bound, not a promise that the connector can create that many useful parallel tasks. The connector's source partitions, the input topic's partitions, its implementation, or the destination's own limits may cap concurrency. Workers supply execution capacity, but they cannot manufacture parallelism that the connector's partitioning model does not expose.
For example, a source reading one inherently serial change log may remain limited even after its task maximum rises. A sink consuming six input partitions cannot obtain twelve independently assigned partitions from that same topic merely by requesting twelve tasks. Examine actual task assignments and per-task rates before scaling. More tasks may also overload the database, exhaust connections, or worsen rate limiting. Scale only after identifying whether the bottleneck is connector CPU, broker I/O, source extraction, or destination writes. Test recovery and rebalance behavior at the new concurrency because higher throughput is not useful if failures create unmanageable recovery delays.
113. How would you define event identity across republishing and schema migrations?
Use an explicit stable event identifier and distinguish it from an entity key and a Kafka location. A topic-partition-offset identifies one stored occurrence, while an entity key such as account ID groups many legitimate events. Republishing into a new topic assigns a different location even when the underlying business event is unchanged.
For example, a schema migration that rewrites historic invoices should preserve the original event identity if downstream consumers must deduplicate the migration against prior delivery. A genuinely new correction needs a distinct identity and a clear relationship to the original event. Document whether each operation is a replay, replacement representation, or new business fact. Test that serialization changes preserve the intended identifier semantics. This contract also helps reconcile cross-cluster copies without incorrectly discarding two legitimate updates to the same account.
114. What should a cross-cluster Kafka disaster-recovery design promise about data loss?
It should promise a measured recovery-point objective based on replication progress, not assume that local acknowledgments imply remote durability. Asynchronous mirroring can leave the destination behind even when producers successfully commit to the source cluster. A regional failure may make the unmirrored tail unavailable, and remote failover also needs topic, security, application, and state readiness.
For example, if the recovery cluster is thirty seconds behind at the moment the primary becomes unreachable, the team must distinguish confirmed remote records from possibly missing ones before resuming critical processing. Track replication lag under peak load and during network degradation, not just its normal average. Define producer fencing or routing controls to prevent both regions from independently accepting conflicting authority during failover. MirrorMaker 2 is useful for cross-cluster replication, but it does not turn two clusters into one synchronous transactional log. Rehearse failover and failback with business-level reconciliation and explicit loss acceptance criteria.
115. Why can consumer offsets not simply be copied numerically during cross-cluster failover?
Offsets identify positions within a particular partition log, and the mirrored destination log is a different log. Replication timing, filtering, topic naming, and record handling can prevent a source offset from referring to the same event at the destination. Offset translation or checkpoint mechanisms are needed, followed by validation of the intended consumption position.
Suppose a consumer committed source offset 1000. Seeking destination offset 1000 without a mapping can skip or repeat business records even if both topics have the same number of partitions. MirrorMaker 2 provides facilities relevant to translating progress, but their configuration, checkpoint freshness, group state, and failover procedure matter. Do not overwrite active destination group progress blindly. Compare business identifiers around the proposed cutover and make consumers resilient to a conservative replay window. Recovery documentation should state which duplicates are acceptable and how to detect missing events, rather than presenting offset migration as a simple integer copy.
116. How would you avoid the database-and-Kafka dual-write problem?
Choose one atomic system-of-record boundary and bridge the other side with a reliable, replayable mechanism. A common design commits the business update and an outbox row in one database transaction, then uses a suitable change-data-capture or outbox publisher to deliver the event to Kafka. That prevents a crash between two independent application writes from leaving a committed business change with no durable publication intent.
The bridge can still deliver duplicates, so include a stable event identifier and make downstream handling idempotent. For Kafka-to-database processing, a destination transaction may combine the business effect with a deduplication or progress record, followed by careful Kafka offset handling. Kafka transactions alone do not atomically commit an arbitrary database transaction. Compare the actual failure windows: before database commit, after commit but before publication, and after publication but before the publisher records progress. A strong answer explains recovery for each interval rather than merely naming the outbox pattern.
117. How would you make a production replay safe for downstream systems?
Separate the replay's scope and identity from normal consumption, and decide which side effects are permitted before moving offsets. Establish the input range, expected record count, retained-data availability, schema compatibility, output destination, and resource budget. A replay that fixes an aggregate can accidentally resend emails, recharge customers, or overwrite newer state if business semantics are ignored.
A safer approach may use a new consumer group and shadow output topic, compare results, and then promote a verified correction. If writing to the existing destination, use stable identifiers, version checks, or idempotent updates appropriate to that destination. Apply quotas so historical traffic does not starve live processing. Record start and end positions per partition rather than treating a topic as one globally ordered sequence. Test a small bounded range first and retain an audit of changes. Resetting offsets changes what Kafka supplies; it does not reverse side effects previously performed outside Kafka.
118. When would you choose separate Kafka clusters instead of shared-cluster multi-tenancy?
Choose separate clusters when the required failure isolation, administrative boundaries, compliance controls, or workload behavior cannot be adequately protected within a shared cluster. ACLs and quotas help share resources safely, but tenants still depend on common brokers, controllers, storage capacity, and operational changes. A cluster-wide outage or badly planned upgrade can affect every tenant.
For example, a latency-sensitive settlement pipeline may not belong beside an experimental workload that creates many short-lived topics and unpredictable backfills, even if both have bandwidth quotas. Separate clusters add cost and operational burden, including independent monitoring, capacity, upgrades, and possible cross-cluster data movement. Compare that cost with the consequences of shared failures. If sharing, establish topic and partition budgets, retention policies, authenticated identities, schema ownership, and clear incident responsibility. Base the decision on measurable isolation needs rather than assuming either one-cluster-per-team or one-cluster-for-everything is universally correct.
119. How would you test Kafka recovery without confusing a restart test with a resilience test?
Define the expected data and availability outcomes, inject a controlled failure in an authorized test environment, and verify business records as well as infrastructure health. Gracefully restarting one broker exercises only a narrow path. Useful scenarios include abrupt process loss, a slow disk, a network partition, controller unavailability, consumer crashes after side effects, and recovery of large Streams state.
Generate records with stable IDs and a known expected result so the test can detect gaps, duplicates, ordering violations within the promised scope, and excessive recovery time. Capture producer outcomes and consumer observations separately because an ambiguous producer timeout is not proof of loss. Avoid destructive experiments on production without explicit approval and safeguards. After the cluster recovers, verify ISR stability, backlog drain, state restoration, and replacement redundancy. A test passes when its predefined guarantees hold through recovery, not merely when every process returns to a running state.
120. What evidence would you require before declaring a Kafka pipeline production-ready?
Require evidence that the pipeline meets its delivery, processing, durability, security, capacity, and recovery objectives under representative load and failure. A successful happy-path producer-consumer demo is necessary but insufficient. Review record keys and ordering assumptions, acknowledgment and replication policies, commit boundaries, schema evolution, retention, monitoring, ownership, and external-side-effect handling as one coherent contract.
For example, a pipeline can have healthy broker metrics while its consumer commits before a database write, creating an avoidable loss window. It can also have correct processing logic but insufficient retention to recover from the longest expected outage. Ask for measured load results, replay and failover exercises, denial tests for unauthorized access, and runbooks with safe stopping points. Confirm that the deployed client, broker, Connect, and Streams versions match the tested compatibility assumptions. Distinguish what was actually executed from what was only reviewed, and record unresolved risks rather than turning a checklist into an unsupported guarantee.
Kafka Documentation and Further Reading
These primary Apache Kafka references use the 4.1 documentation tree for a coherent baseline. Consult the matching upgrade and compatibility documentation before applying examples to another release. Third-party connectors and schema registries have additional behavior and guarantees outside Apache Kafka core.
Similar Posts