Kafka engineer interview questions

As asked

You are designing an orders topic with 50,000 events per second. How do you choose the partition key, and what can go wrong?

Sample answer outline

The partition key controls ordering, load distribution and consumer parallelism, so it should match the ordering requirement first. If all events for an order must be processed in sequence, orderId is a natural key; if customer-level ordering matters, customerId may be required but can create hot partitions. The number of partitions should allow enough consumer parallelism without creating unnecessary broker overhead. The answer should discuss skew, key cardinality, compaction needs and future repartitioning pain. Candidates often say random keys for balance while missing that this destroys per-entity ordering.

Expect these follow-ups

• How would you detect a hot partition in production?
• What happens to ordering when you increase partition count?
• When would you split one logical stream across multiple topics?

As asked

You find an unsafe block around a C library call in a production Rust service. What invariants do you check before approving the change?

Sample answer outline

The answer should make the safety contract explicit: pointer validity, alignment, ownership, aliasing, lifetime, thread-safety, error handling and cleanup responsibilities. Unsafe should be isolated behind a small safe abstraction whose public API prevents callers from violating those invariants. FFI return codes and null pointers need to become Rust Result or Option values immediately. The candidate should mention tests that exercise boundary cases and tooling such as Miri, sanitizers or fuzzing where practical. A weak answer treats unsafe as a local syntax escape hatch rather than a module-level proof obligation.

Expect these follow-ups

• How do you document a safety invariant without making every caller read C headers?
• What is the difference between unsafe to call and unsafe inside?
• How would you fuzz this boundary?

As asked

A consumer reads from Kafka, writes to a database and then commits offsets. Explain at-least-once, at-most-once and exactly-once behaviour in this flow.

Sample answer outline

If the consumer commits before the database write, a crash can lose the message, which is at-most-once. If it writes first and commits after, a crash between those operations can replay the message, which is at-least-once. Exactly-once for external side effects requires idempotent writes, transactions that include both offset and output, or a design where replay is harmless. Kafka transactions help when consuming and producing back to Kafka, but they do not magically make an arbitrary database update exactly once. Strong candidates discuss idempotency keys and deduplication tables.

Expect these follow-ups

• Where would you store an idempotency key?
• How do Kafka transactions work when the sink is another Kafka topic?
• What is the operational cost of exactly-once processing?

As asked

Multiple teams produce and consume the same Kafka topic. How would you manage schema evolution without breaking consumers?

Sample answer outline

Use a schema registry with a compatibility mode that matches the organisation's deployment reality, often backward or full transitive compatibility. Producers should only add optional fields or fields with defaults unless a versioned topic or migration plan is in place. Consumers should ignore unknown fields and tolerate missing optional values. The answer should cover contract tests, ownership of event definitions and a deprecation process for fields that are no longer used. Candidates often miss that event schemas are public APIs with slower migration cycles than service internals.

Expect these follow-ups

• When would you create a new topic instead of evolving the schema?
• How do Protobuf and Avro differ for compatibility?
• What breaks if a producer reuses a field name with different meaning?

As asked

A Scala service ingests events, enriches them over HTTP and writes to Kafka. How would you use Akka Streams or a similar streaming library to control backpressure?

Sample answer outline

The stream should model bounded stages explicitly rather than spawning untracked futures. mapAsync with a fixed parallelism caps HTTP concurrency, buffers should be sized intentionally, and supervision should define whether a bad record is skipped, retried or sent to a dead-letter path. Kafka commits should be tied to successful processing so replay semantics are clear. The answer should mention materialised values, kill switches and graceful shutdown. Candidates often add buffers everywhere, which hides overload until latency and memory fail together.

Expect these follow-ups

• Where would you put retries and how would you avoid retry storms?
• How do you choose mapAsync parallelism?
• What happens during shutdown with in-flight messages?

As asked

A GenServer that batches analytics events starts building a mailbox with millions of messages during a traffic spike. How do you debug it and redesign it?

Sample answer outline

The diagnosis should inspect process info, message queue length, reductions, memory, and the shape of incoming messages before guessing. The redesign should avoid treating a GenServer as an unbounded queue: use bounded demand, partition work across multiple processes, and push durable backlog into Broadway, Oban, RabbitMQ, or Kafka depending on delivery requirements. Batching should be time and size bounded, with explicit shedding or backpressure when downstream is slow. A senior answer distinguishes CPU saturation from downstream latency and from a single hot key. The common mistake is adding more callers while leaving one serial bottleneck in place.

Expect these follow-ups

• How would you expose mailbox length as an operational metric?
• When is dropping events acceptable?
• How would Broadway change the design?