Kafka Scenarios, Labs, Gotchas, and Production Traps
Answer First: Kafka interview scenarios are solved by first naming the partitioning contract, then the delivery contract, then the operational failure mode.
Memory Map: scenario -> partition key -> delivery semantic -> lag/rebalance risk -> durability config -> recovery test.
Single-node Kafka lab
Answer First: The fastest hands-on proof is: start a local broker, create a topic, produce records, consume from the beginning, and describe the consumer group.
Memory Map: docker broker -> create topic -> produce records -> consume replay -> describe group -> prove offsets.
kafka-topics.sh --create --topic orders --partitions 3 --replication-factor 1
kafka-console-producer.sh --topic orders
kafka-console-consumer.sh --topic orders --from-beginning
Observe partitioning by key
Answer First: Produce several records with the same key and print partitions while consuming; the repeated key should land on the same partition.
Memory Map: keyed produce -> partition print -> same key grouping -> per-key order -> rescale warning.
Use this lab to make ordering concrete: Kafka orders records by partition, not by whole topic.
Visual flows to draw in interviews
Answer First: Draw producer-to-broker-to-consumer flow, ISR shrink and re-election, and compaction; these three pictures cover most Kafka whiteboard prompts.
Memory Map: producer flow -> broker leaders -> consumer offsets -> ISR shrink -> compaction cleaner -> failure tradeoff.
Production gotchas
Answer First: The common Kafka failures are partition rehashing, weak acknowledgements, lag hotspots, wrong offset reset, heartbeat starvation, and oversized messages.
Memory Map: partition increase -> key reorder risk -> acks one loss -> lag hotspot -> poll timeout -> message-size envelope.
Interview-safe fixes: plan partitions early, use acks=all, monitor lag by partition, set auto.offset.reset=earliest for replay, keep processing under max.poll.interval.ms, and align broker/topic/consumer size limits.
Event-driven order system scenario
Answer First: Partition orders by customer, let inventory/payment/shipping read as independent groups, emit service-specific event topics, and use idempotency plus DLQs for safe retries.
Memory Map: order event -> customer partition -> independent service groups -> outcome topics -> idempotent write -> DLQ.
This is the default Kafka design prompt: separate command processing from event observation, then make duplicates harmless.
Partition sizing scenario
Answer First: More partitions increase parallelism but also increase metadata, file handles, elections, and rebalance work; choose partitions from throughput and ordering needs, not vibes.
Memory Map: target throughput -> per-partition budget -> consumer parallelism -> metadata overhead -> rebalance time -> future growth.
Keep a sizing story ready: estimate MB/s, divide by safe throughput per partition, then validate with a load test.