We use cookies for site analytics. Accept to help us understand how the site is used. See our Privacy Policy for details.
Partitions, consumer groups, replication, retention, and the exactly-once myth - the implementation details Kafka users gloss over until they don't.
Design a distributed message queue that ingests millions of messages per second, durably stores them across machine and data-center failures, lets independent consumer groups read at their own pace, supports replay, and provides ordering guarantees within a partition.
This is "implement Kafka" framed as a system design question. Strong candidates separate the on-disk log structure, the replication protocol, the consumer offset model, and the operational concerns (rebalances, partition rebalancing, broker failures). Weak candidates draw a queue and stop. The signal is depth - everyone knows what Kafka does; few know how.
Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.
Capacity estimation · architecture with all 9 components explained · 6 deep dives · trade-off analysis · 8 common follow-up questions
Get full access to gitGood.dev with a subscription.
Try everything free for 10 days. Cancel anytime.
10-day trial, then $5/mo - or $40/yr ($3.33/mo, save 33%). Cancel anytime.
Fan-out at write vs read, at-least-once vs exactly-once, dead-letter queues, and the multi-channel delivery problem - one message, ten failure modes.
Batch vs streaming, lambda vs kappa, the warehouse-vs-lakehouse decision, and dimension modeling that survives schema drift.
Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.
Start an AI mock interview →