Kafka Interview Questions and Answers

What interviewers are testing: Whether you connect Kafka concepts to Java/Spring Boot integration—producers, listeners, and test containers—not broker theory alone.

Java developer loops add client integration depth on top of broker concepts:

Interviewers often ask you to sketch Spring Boot properties for a producer and consumer in the same service—see Spring Boot interviews for broader microservice context.

A strong answer is:

A Java Kafka interview adds client-side depth to broker fundamentals: producer configuration, serializers, KafkaTemplate, @KafkaListener, consumer concurrency, error handling, transactions, and integration testing. I need to connect those APIs back to partitions, offsets, and delivery guarantees.

What interviewers are testing: whether you position Kafka as a distributed commit log—not a traditional message queue.

Kafka is a distributed event streaming platform built around an append-only partitioned log. Producers append records; consumers pull and track position via offsets.

Kafka fits event sourcing, audit trails, stream processing, and decoupled microservices where many teams read the same history.

A strong answer is:

Kafka is a durable, replayable log with pub/sub via consumer groups—not a delete-on-read queue—so multiple services can consume the same topic at different speeds and rewind when needed.

What interviewers are testing: Whether you can distinguish Kafka's data plane—producers, brokers, partition leaders/replicas, and consumers—from the KRaft control plane that manages cluster metadata and leadership.

Data flow: producer → partition leader → followers replicate → consumers fetch.

A strong answer is:

Brokers host partition leaders and replicas; producers write to leaders; consumer groups divide partitions among members; the controller handles metadata and leader election.

What interviewers are testing: whether you explain topics as logical streams and partitions as parallelism/ordering units.

A topic is a logical category of records. Each topic is split into partitions—physical logs on disk.

Partition count is chosen at topic creation—increasing partitions adds parallelism but can change which partition future records for a key map to, so you cannot assume per-key history stays on one partition after repartitioning.

With standard Kafka partitioning, records with the same serialized key are deterministically routed to the same partition while the topic's partition count remains unchanged.

A strong answer is:

A topic is the stream name; partitions are the ordered shards that enable scale—I choose partition count and keys so ordering and throughput match product rules, and I treat repartitioning as a breaking change for key locality.

What interviewers are testing: whether you know ordering is per-partition only—partition key choice is the design decision.

Ordering: Kafka guarantees order per partition. If you need all events for order-123 ordered, use key = order-123 so they land in one partition.

Delivery is not one setting—it is a stack of choices:

There is no global order across partitions—design for partition-local order or use a single partition (limits throughput).

A strong answer is:

Ordering is per partition via key routing; end-to-end delivery semantics come from producer acks, replication, and consumer offset timing together.

What interviewers are testing: whether you explain KRaft replacing ZooKeeper for metadata quorum in modern Kafka clusters.

KRaft (Kafka Raft) stores cluster metadata in Kafka itself using a Raft quorum.

Kafka 4.x is KRaft-only. ZooKeeper mode was removed in Kafka 4.0. Current Apache Kafka documentation is KRaft-centric.

Interviewers still ask about ZooKeeper for migration planning on older clusters—not for greenfield design.

A strong answer is:

Modern Kafka runs in KRaft mode; Kafka 4.x no longer supports ZooKeeper. I still understand ZooKeeper because older clusters may need migration planning, but I would not design a new cluster around it.

What interviewers are testing: Whether you can trace serialization, partition selection, batching, leader writes, replication, acknowledgements, and retries—and identify where latency, ordering, or duplication can enter the path.

Simplified produce path:

1. Serializer turns key/value into bytes
2. Partitioner picks partition (key hash or sticky batching)
3. Producer batches records for throughput
4. Request sent to partition leader broker
5. Leader appends to log; followers replicate
6. Broker responds based on acks setting
7. On failure, producer retries (may duplicate without idempotence)

Batching (linger.ms, batch.size) trades latency for throughput.

A strong answer is:

The producer serializes, partitions, batches, and sends to the leader; replication and ack level determine when the produce call succeeds and whether retries can create duplicates.

What interviewers are testing: whether you map acks=0/1/all to durability vs latency and tie acks=all to min.insync.replicas.

Pair acks=all with min.insync.replicas on the broker/topic. min.insync.replicas sets the minimum number of in-sync replicas, including the leader, that must be available for an acks=all write to succeed; acks=all then waits for all replicas in the current ISR. acks=all alone does not mean "every replica in every situation."

Use acks=0 only for metrics or logs where loss is acceptable.

A strong answer is:

acks=0 is fire-and-forget, acks=1 waits for the leader, acks=all gives the strongest producer acknowledgement guarantee—I pair all with min.insync.replicas and RF≥3 for meaningful durability.

What interviewers are testing: whether you know record keys route to partitions—same key preserves order within a partition.

The key determines partition (when non-null):

Use cases:

• orderId as key — all lifecycle events for one order stay ordered
• userId — per-user ordering
• Null key — maximum spread when order does not matter

Hot keys can create partition skew—one partition overloaded while others idle.

Increasing the partition count can change which partition future records for a key map to—you cannot assume per-key history remains in a single partition after repartitioning.

A strong answer is:

Keys route related events to the same partition for ordering while partition count is stable; I avoid hot keys and treat repartitioning as a breaking change for key locality.

What interviewers are testing: whether you explain idempotent producer PID/sequence dedup within a producer session.

Modern Kafka producers enable idempotence by default when no conflicting settings disable it. You can explicitly set enable.idempotence=true when you want configuration errors to fail rather than silently disabling idempotence.

Broker assigns Producer ID (PID) and tracks sequence numbers per partition—duplicate retries are deduplicated within that producer session.

Idempotence requires acks=all (the modern default), retries > 0 (effectively very high by default), and max.in.flight.requests.per.connection ≤ 5.

A strong answer is:

Idempotence prevents duplicate writes caused by producer retries using producer IDs and sequence numbers. Modern clients normally enable it by default, but I still verify that my acks and in-flight settings do not conflict with it.

What interviewers are testing: Whether you understand how acks, retries, idempotence, delivery timeout, batching, compression, and in-flight requests interact rather than tuning each producer property independently.

Misconfigured max.in.flight.requests.per.connection with retries and no idempotence can reorder batches—classic interview trap.

A strong answer is:

I tune acks, idempotence, and in-flight requests together, and I batch with linger/batch.size only after measuring latency impact.

What interviewers are testing: whether you describe one consumer per partition per group and what happens when consumers scale.

A consumer group shares one group.id. Each partition is assigned to exactly one consumer in the group at a time.

Different groups reading the same topic are independent—each maintains its own offsets (fan-out).

Consumer group assignment simulation:

def assign_partitions(partitions, consumers):
    assignments = {consumer: [] for consumer in consumers}

    for i, partition in enumerate(partitions):
        consumer = consumers[i % len(consumers)]
        assignments[consumer].append(partition)

    return assignments


parts = [f"P{i}" for i in range(6)]

print(assign_partitions(parts, ["C0", "C1", "C2"]))

This is only a simple illustration of partition distribution; Kafka's actual assignment depends on the configured group protocol and assignor.

When you click Run, you should see each consumer name mapped to two partition labels—round-robin style assignment similar in spirit to range/round-robin assignors.

A strong answer is:

A consumer group divides partitions among members so each partition is processed once per group; extra consumers stay idle unless I add partitions.

What interviewers are testing: whether you explain committed offsets as resume points—auto vs manual commit trade-offs.

Each record has an offset within its partition. A consumer's committed offset normally represents the next offset it should resume from, not simply "the record it last processed." Committed offsets are stored in the internal topic __consumer_offsets.

At-least-once pattern: process record, then commit offset.

At-most-once pattern: commit offset, then process (may lose on crash).

A strong answer is:

Offsets are the consumer's bookmark—I commit after successful processing for at-least-once, and I disable careless auto-commit on critical pipelines.

What interviewers are testing: Whether you can identify membership, timeout, deployment, and metadata changes that cause rebalancing and choose mitigations such as cooperative assignment, static membership, and correct poll/heartbeat configuration.

Rebalance redistributes partitions when group membership changes:

• Consumer joins or leaves
• Consumer exceeds session timeout / max.poll.interval.ms (classic protocol)
• Topic partition count changes
• Assignment strategy revokes partitions

Classic group protocol (group.protocol=classic):

New consumer group protocol (group.protocol=consumer):

• Broker-side assignment and group management (Kafka 4.x)
• Heartbeat and session timing controlled by broker settings such as group.consumer.heartbeat.interval.ms and group.consumer.session.timeout.ms
• Client heartbeat.interval.ms / session.timeout.ms do not apply the same way

Mitigations (classic and new):

• Right-size poll intervals; avoid long processing in the poll loop
• Static membership (group.instance.id) for rolling restarts
• Know which group protocol your clients use before tuning timeouts

A strong answer is:

Rebalances happen on membership or timeout changes—I know whether the group uses classic or the new consumer protocol, use cooperative assignors on classic where appropriate, and keep processing off the poll thread for long work.

What interviewers are testing: whether you debug lag with partition-level metrics, rebalance events, and processing time—not just restart consumers.

Lag = difference between log end offset and consumer committed/current offset—how far behind a consumer is.

Tools: kafka-consumer-groups.sh --describe, Burrow, Datadog, Prometheus exporters.

Fix: scale consumers (up to partition count), optimize handler, increase partitions with key strategy review, fix poison messages.

A strong answer is:

Lag is how far behind consumption is—I find whether the bottleneck is processing time, partition skew, or rebalance churn, then scale or fix handlers with metrics, not guesses.

What interviewers are testing: whether you connect max.poll.interval.ms and session.timeout.ms to slow processing and false rebalances.

Classic consumer group protocol (group.protocol=classic):

New consumer group protocol (group.protocol=consumer):

• Heartbeat interval is broker-managed via group.consumer.heartbeat.interval.ms
• Session timeout is broker-managed via group.consumer.session.timeout.ms
• Client heartbeat.interval.ms and session.timeout.ms are not supported in the same manner

max.poll.interval.ms still matters in both protocols—if your listener blocks poll() too long, the consumer can be removed from the group.

Pattern: poll often, hand off to worker pool, use pause/resume for backpressure.

If processing records outside the poll thread, keep KafkaConsumer access on its owning thread and coordinate offset commits carefully so completed work, partition ordering, and rebalances remain correct.

A strong answer is:

On classic protocol, session.timeout detects dead members and max.poll.interval caps time between polls. On the new consumer protocol, brokers manage heartbeat/session timing—I still never block the poll loop on long synchronous work.

What interviewers are testing: whether you know read_committed hides open transactions from consumers.

Consumers default to read_uncommitted—see all messages including those from aborted transactions.

With isolation.level=read_committed, consumers hide aborted transactional records and only return records up to the last stable offset (LSO); data after an open transaction may remain temporarily invisible until that transaction commits or aborts.

Pair with transactional producers and disabled auto-commit.

A strong answer is:

read_committed prevents consumers from observing aborted transactional output and stops at the last stable offset while transactions are open; it is required when downstream consumers must respect Kafka transaction boundaries.

What interviewers are testing: whether you explain leader/follower replication and ISR for durability.

Each partition has replication factor N—one leader and N−1 followers on different brokers.

Producer acks=all waits for ISR acks—not merely any replica.

A strong answer is:

Replication across brokers plus ISR tracking and safe leader election keeps partitions available after node loss—I pair that with acks=all and min.insync.replicas.

What interviewers are testing: whether you define ISR as in-sync replicas eligible for leader election—out-of-sync followers lag.

ISR contains replicas that are sufficiently caught up with the leader according to broker replication-lag rules (historically tied to replica.lag.time.max.ms).

Only ISR members can become leader if unclean.leader.election.enable=false.

If ISR shrinks to one replica:

• Reads and some writes may continue
• Producers with acks=all fail writes if ISR falls below min.insync.replicas
• No redundancy until followers catch up
• Risk if that single broker fails

Monitor ISR shrink events—they predict durability risk.

A strong answer is:

ISR is the set of replicas safe to promote—I alert when ISR size drops and I connect ISR shrink to min.insync.replicas failures for acks=all producers.

What interviewers are testing: whether you tie min.insync.replicas to acks=all durability—writes fail if ISR shrinks below minimum.

Broker/topic setting min.insync.replicas sets the minimum ISR size required to accept an acks=all write; with acks=all, all replicas currently in the ISR must acknowledge.

Example: replication.factor=3, min.insync.replicas=2

• Tolerates one broker loss without stopping writes
• Producer with acks=all fails if only one ISR member available—prefer failing writes over silent data loss

Interview trap: acks=all with min.insync.replicas=1 and RF=3 still allows single-replica commits.

A strong answer is:

min.insync.replicas sets the minimum ISR size required to accept an acks=all write. With RF=3 and min ISR=2, I can lose one replica and still write without falling back to single-copy durability.

What interviewers are testing: whether you walk leader election, ISR shrink, and consumer rebalance when a broker dies.

Clients refresh metadata and discover new leaders—brief produce/fetch errors during election.

Operations: rack awareness (broker.rack) for cross-AZ placement, monitor under-replicated partitions.

A strong answer is:

Follower loss reduces redundancy; leader loss triggers ISR election; clients retry after metadata refresh—I design RF and rack awareness so single-AZ loss does not take topics offline.

What interviewers are testing: Whether you distinguish producer durability from consumer processing semantics and can explain exactly where loss or duplicate processing occurs around an offset commit.

Producer settings such as acks and idempotence affect durability and duplicate writes on the broker—they do not by themselves define consumer at-most-once or at-least-once processing.

Simple timelines:

At-most-once: commit offset → process → crash → work may be lost

At-least-once: process → crash → offset not committed → record delivered again

A strong answer is:

At-most-once commits early; at-least-once commits after work and may retry duplicates; exactly-once is a scoped guarantee for Kafka-to-Kafka transactional processing—not magic for external databases.

What interviewers are testing: whether you explain EOS via idempotent producer + transactions in consume-transform-produce flows.

Broker-side pieces:

1. Idempotent producer — dedupe per-partition retries
2. Transactions — initTransactions, beginTransaction, commitTransaction
3. sendOffsetsToTransaction — atomic offset commit with output records
4. Consumer isolation.level=read_committed

Application-side: processing must be deterministic; external sinks need idempotent writes or transactional stores—EOS in Kafka does not magically dedupe your database.

Kafka Streams offers processing.guarantee=exactly_once_v2 packaging the pattern.

A strong answer is:

Exactly-once is a scoped guarantee, not magic. Kafka can provide EOS for Kafka-to-Kafka transactional processing; external side effects still need their own idempotency or transaction strategy.

What interviewers are testing: whether you walk a transactional consume-transform-produce with commit/abort boundaries.

Steps:

1. Producer initTransactions()
2. Consumer polls records
3. beginTransaction()
4. Process and produce output records
5. sendOffsetsToTransaction with consumed offsets
6. commitTransaction() — all visible or none

On failure: abortTransaction() — consumers with read_committed never see partial output.

Requires unique transactional.id per producer instance (fence zombies after failover).

A strong answer is:

I put output records and consumed offsets in one Kafka transaction so downstream read_committed consumers see either the committed result and offset together or neither.

What interviewers are testing: whether you know at-least-once still needs idempotent handlers—offsets commit after processing.

Most teams run at-least-once (simpler than full transactions). Retries and rebalance redelivery mean duplicate delivery is normal.

Consumer strategies:

"Exactly-once" in interviews often means effective exactly-once—at-least-once transport + idempotent processing.

A strong answer is:

At-least-once will redeliver—I design handlers to dedupe on business keys or store processed IDs so duplicates are harmless.

What interviewers are testing: whether you explain Schema Registry for Avro/JSON schema evolution in event contracts.

Apache Kafka does not include a built-in Schema Registry. Many organizations pair Kafka with an ecosystem registry such as Confluent Schema Registry, Apicurio Registry, or AWS Glue Schema Registry to version Avro, Protobuf, or JSON Schema contracts.

Common Confluent-style wire format: producers send a schema ID; consumers fetch the schema from the registry. The exact schema-ID format depends on the registry and client implementation—not a universal Kafka rule.

A strong answer is:

Kafka does not ship a universal schema registry—I use a registry product for versioned contracts and test backward-compatible evolution in CI.

What interviewers are testing: whether you position Connect as managed source/sink integration—not custom producer code for every system.

Kafka Connect is a framework for source and sink connectors:

Runs as distributed workers with offset tracking in Kafka—fits ETL without custom consumer boilerplate.

Pair with SQL interviews when discussing CDC and warehouse loads.

A strong answer is:

Kafka Connect moves data in and out with connectors—I use CDC sources and managed sinks instead of one-off consumers when the pattern is standard.

What interviewers are testing: whether you describe Kafka Streams as embedded stream processing on the log—not a separate cluster.

Kafka Streams is a Java library for stream processing on top of Kafka:

• Stateful operations (aggregations, joins) with changelog topics
• Exactly-once v2 processing guarantee option
• No separate cluster like Flink—runs as your app

Kafka Streams fits Kafka-centric JVM applications that want an embedded processing library. Flink is often preferred when the organization needs an independent stream-processing runtime, broader connector ecosystem, complex distributed processing, or operational features that justify a dedicated platform.

A strong answer is:

Kafka Streams embeds processing in Java apps with state stores and EOS options—I choose it for JVM microservices, Flink when operability needs a dedicated cluster.

What interviewers are testing: whether you contrast compacted topics (latest key wins) vs time retention.

Compaction suits changelog topics—config snapshots, __consumer_offsets, compacted state topics in Streams.

A compacted topic is not guaranteed to contain only one physical record per key at every instant—not a substitute for infinite raw event history.

A strong answer is:

Time retention drops old data by age; compaction keeps the latest value per key for changelog-style topics like config or state stores.

What interviewers are testing: whether you explain retention.ms/bytes and compaction impact on replay and disk.

Long retention enables replay for new consumer groups or reprocessing—costs disk.

Modern Kafka supports tiered storage / remote log storage architectures that keep older log segments in remote storage while retaining recent data locally. Apache Kafka provides the tiered-storage framework but not a production RemoteStorageManager implementation out of the box, so deployment requires a compatible storage plugin or distribution. Remote fetches are not equivalent in latency to local reads, and current Apache Kafka docs note limitations including no support for compacted topics in tiered storage.

A strong answer is:

Retention balances replay needs and disk cost—I size per topic and use tiered/remote storage when long retention would otherwise exhaust broker disks.

What interviewers are testing: whether you name under-replicated partitions, offline replicas, request latency, and consumer lag as production signals.

Alert on lag SLO breach and URP > 0 sustained—not only broker up/down.

A strong answer is:

I monitor lag, under-replication, and disk—I tie alerts to consumer SLOs and broker health, not just process running.

What interviewers are testing: whether you size partitions for parallelism and disk for retention—not one partition per message.

Load test with expected message size and compression; watch disk I/O and network.

A strong answer is:

I size partitions for peak consumer parallelism and key ordering needs, then load-test brokers—partition count is hard to reduce later.

What interviewers are testing: whether you handle poison pills with DLQ, skip, or quarantine—not infinite retry loops.

Poison message — fails processing every retry, blocks partition or causes infinite loop.

Patterns:

Always log key, offset, partition, stack trace; alert on DLT rate.

A strong answer is:

I cap retries, route failures to a dead-letter topic with metadata, and alert—never spin forever on the same offset without visibility.

What interviewers are testing: whether you cover SASL, TLS, and ACLs for multi-tenant Kafka clusters.

Never expose plaintext brokers to the public internet; rotate credentials; least-privilege ACLs per producer/consumer principal.

A strong answer is:

TLS plus SASL authentication and topic-level ACLs—I give each service only produce or consume rights on the topics it needs.

What interviewers are testing: whether you pick Kafka for log/replay/streaming vs RabbitMQ for task queues—not either-or dogma.

Pick RabbitMQ for RPC-style work queues; Kafka for event streams, audit logs, and multiple independent readers.

A strong answer is:

RabbitMQ for task routing and low-latency queues; Kafka for durable event streams, replay, and high-throughput fan-out—I do not force all messaging through one tool.

What interviewers are testing: whether you design immutable events with schema versioning—not chatty CRUD on the bus.

Practices:

Align with full stack and Spring Boot service boundaries.

A strong answer is:

Events are contracts—I name them as facts, version schemas, include correlation IDs, and design consumers to tolerate redelivery.

What interviewers are testing: whether you explain CDC as change capture into Kafka for downstream sync and analytics.

CDC streams database row changes to Kafka—often Debezium on Kafka Connect.

Challenge: ordering per key, schema changes, initial snapshot load.

For service-owned domain events, a common pattern is transactional outbox + CDC: write the business row and outbox row in one database transaction, then let Debezium/Connect publish the outbox record to Kafka. This avoids an application-level database+Kafka dual write.

A strong answer is:

CDC publishes database changes as events—I use Debezium for near-real-time sync instead of brittle dual-write patterns between services and DBs.

What interviewers are testing: whether you configure producer acks, retries, and serializers in Spring Boot with error handlers.

Add spring-kafka and configure:

spring.kafka.bootstrap-servers=localhost:9092
spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.producer.value-serializer=org.springframework.kafka.support.serializer.JsonSerializer
spring.kafka.producer.acks=all
# Idempotence is enabled by default on modern clients; explicit setting fails fast on conflicts
spring.kafka.producer.properties.enable.idempotence=true

@Service
@RequiredArgsConstructor
public class OrderEventPublisher {
    private final KafkaTemplate<String, OrderPlacedEvent> kafkaTemplate;

    public void publish(OrderPlacedEvent event) {
        kafkaTemplate.send("orders", event.orderId(), event);
    }
}

Use orderId as key for partition locality. Configure retries and delivery timeout explicitly for critical topics.

A strong answer is:

Spring Kafka wraps KafkaTemplate with serializers and producer props—I set acks, idempotence, and keys explicitly for durable ordered per-order events.

What interviewers are testing: whether you set @KafkaListener concurrency, group id, and error handlers for production consumers.

@Component
@Slf4j
public class OrderListener {

    @KafkaListener(topics = "orders", groupId = "billing-service", concurrency = "3")
    public void onOrder(OrderPlacedEvent event) {
        log.info("billing {}", event.orderId());
    }
}

Disable enable-auto-commit when you need explicit offset control. In Spring Kafka, manual acknowledgement behavior depends on the listener-container AckMode (MANUAL, MANUAL_IMMEDIATE, etc.)—calling acknowledge() does not by itself define complete commit semantics.

@KafkaListener(...)
public void listen(ConsumerRecord<String, OrderPlacedEvent> record, Acknowledgment ack) {
    process(record.value());
    ack.acknowledge(); // Semantics depend on configured AckMode.
}

DefaultErrorHandler and dead-letter topic behavior also interact with ack mode and transaction configuration—treat examples as conceptual unless the container factory is fully defined.

A strong answer is:

I match listener concurrency to partitions, configure AckMode explicitly for at-least-once discipline, and wire error handlers to dead-letter topics instead of infinite retry loops.

What interviewers are testing: Whether you separate pure handler tests from broker integration tests and use real Kafka only where serialization, consumer-group, transaction, or acknowledgement behavior matters.

Assert with KafkaTestUtils.getSingleRecord or awaitility on side effects.

Mirror Spring Boot testing pyramid—many handler unit tests, few full broker tests.

A strong answer is:

I unit-test handlers without Kafka, use EmbeddedKafka or Testcontainers for wiring tests, and keep broker tests focused on serialization and ack behavior.

What interviewers are testing: whether you triage lag spikes after deploy—rebalance, slower processing, or offset reset—not blind scale-out.

A strong answer is:

I isolate the group and partition skew, compare release timing, inspect handler latency and rebalances, then fix code or scale consumers with metrics proving the bottleneck.

What interviewers are testing: whether you contrast classic vs consumer group protocol rebalance behavior in modern Kafka.

Kafka 4.x clients support two consumer group protocols:

Migrations require client and broker compatibility awareness. Configuration semantics differ—do not assume session.timeout.ms tuning applies the same way on both.

A strong answer is:

Classic protocol means client assignors and client heartbeat tuning; the new consumer protocol shifts more group management to brokers—I know which protocol my services use before I tune timeouts or debug rebalances.

What interviewers are testing: whether you explain share groups as queue-style consumption alongside traditional consumer groups.

Traditional consumer groups assign partitions exclusively to members—each partition is owned by one consumer at a time.

Share groups became production-ready in Kafka 4.2 and remain part of the modern Kafka 4.x consumption model. They support a more queue-like shared-record consumption model where records can be shared among consumers with acknowledgement semantics rather than fixed partition ownership.

Useful when strict per-partition ownership semantics are not ideal for the workload.

A strong answer is:

Consumer groups give exclusive partition ownership for ordered, parallel consumption; share groups became production-ready in Kafka 4.2 and trade that model for shared-record delivery when queue-like semantics fit better.

What interviewers are testing: whether you know tiered/remote storage moves cold segments off broker disks while keeping metadata local.

Modern Kafka can keep recent/hot segments on local broker storage while moving older segments to remote storage (tiered/remote log storage architecture).

Benefit: longer retention without exhausting broker disks. Apache Kafka supplies the RemoteStorageManager interface but does not provide an out-of-the-box production implementation; deployment requires a compatible storage plugin or distribution. Trade-off: remote fetches are not equivalent in latency to local reads, and compacted topics are not supported in tiered storage per current Apache Kafka docs.

A strong answer is:

Tiered storage lets me retain more history without sizing every broker for full retention locally—I plan for remote-read latency and verify what my distribution actually supports in production.

What interviewers are testing: Whether you know that increasing partition count can change future key-to-partition mapping, splitting one key's historical and future records across partitions and breaking assumptions about continuous per-key ordering.

Adding partitions is a common production trap:

A strong answer is:

Adding partitions increases future parallelism but can change key placement and therefore ordering assumptions—I treat partition count as a data-model decision, not an autoscaling knob.

What interviewers are testing: whether you explain earliest vs latest reset when no committed offset exists or after group reset.

auto.offset.reset defines where to start when the group has no valid committed offset for a partition:

This applies only when there is no committed offset—not every time the consumer starts. A common interview trap is assuming reset runs on every restart.

A strong answer is:

auto.offset.reset is my fallback when no committed offset exists—earliest for backfill, latest for forward-only consumers—and I do not confuse it with normal restart behavior.