We use analytics and advertising cookies to understand how the site is used and whether our ads on Facebook and Instagram work. They are set only if you accept. 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
Unlock it with a subscription.
Try everything free for 7 days. Cancel anytime.
7-day trial, then $8/mo - or $48/yr ($4/mo, save 50%). 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.
Mock interview: design Message Queue →