Design Kafka
hardOpen designCommonly asked~45 minHLD roundBar raiserSenior / SDE-3AmazonNetflixUberMicrosoftAtlassianFlipkartQueues & AsyncStorage & Data ModellingConsistency & ConsensusResilience
The question, as asked
“Design a distributed message queue. Producers write, consumers read, nothing is lost, and it keeps up with millions of messages a second.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Log or queue? A replayable log where consumers track their own position is a different system from a work queue with per-message acknowledgement and redelivery. The prompt says 'queue' but 'millions a second' says log — resolve that out loud.
- What ordering is required? Global ordering across a topic is effectively unscalable; per-key ordering is both achievable and what people actually need.
- What delivery guarantee: at-most-once, at-least-once, or exactly-once? And push back gently on exactly-once — it's achievable only within specific bounds, and saying so is the right answer.
- Retention: discard after acknowledgement, or keep for days so consumers can replay? Replay is what makes a log valuable, and it changes the storage design completely.
- Message size and throughput together — millions of small events is a different machine from thousands of megabyte payloads.
- How many consumers per topic, and do they need independent positions? Multiple independent consumer groups is the fan-out property that makes a log beat a traditional queue.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.