Kafka engineer system design interview questions

As asked

A Rust service reads from Kafka, calls an HTTP dependency, and writes results to Postgres. How would you design backpressure so it fails predictably under load?

Sample answer outline

A good design bounds every queue and makes overload visible before memory grows without limit. Kafka polling should be tied to downstream capacity, with pause and resume or controlled commit lag rather than unbounded task spawning. HTTP concurrency should be capped with a semaphore and short deadlines, while Postgres writes should use bounded batches and connection pool limits. The service should expose lag, queue depth, retry counts and dropped or dead-lettered messages. Candidates often miss cancellation and shutdown semantics, especially making sure in-flight work is either committed or replayable.

Expect these follow-ups

• Where do you commit offsets in this pipeline?
• How do you distinguish a slow dependency from a poison message?
• What metrics would page you before users notice?

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

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?