Design an in-memory message queue
PremiumLow-level designHard
- Producer consumer
- Dead letter queue
- Backpressure
Quick answer
This low-level design interview question asks you to design an in-memory message queue. Aim for a design that is modelled as clear classes, interfaces and relationships that can handle new requirements without a rewrite. Interviewers want to see how you name responsibilities, keep classes small and reason about change.
The problem
In-memory message queue low level design: build an in-process library where producers publish to topics and consumer groups receive and acknowledge messages. The hard parts are at-least-once delivery with retries, backpressure within a fixed memory budget, and 500,000 messages per second across threads.
Each topic can have several consumer groups, and within a group each message is handled by one consumer. Messages that fail too many times go to a dead-letter topic. The queue has a fixed memory budget and must slow producers down rather than grow without bound.
What must an in-memory message queue do?
- Topics: Create a topic by name with a capacity and a retention rule (drop oldest when full, or block producers).
- Publish: publish(topic, message) with an optional key; messages with the same key must be delivered in order within a group.
How well must it do it?
- Throughput: 500,000 messages per second on one machine with 16 producer threads and 32 consumer threads across topics.
- Latency: Publish and receive under 100 µs at the median when the topic is not full.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Producer consumer
- Dead letter queue
- Backpressure
- At least once delivery
- Pub sub
- Ring buffer
How you’ll practise
- Requirements
- Core objects
- Class relationships
- Key flows
- Extensibility
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any low-level design round.
- Lists the use cases before writing classes
- Gives each class one clear responsibility
- Uses interfaces where behaviour is likely to change
- Applies a design pattern only when it solves a real problem
- Handles edge cases and invalid states explicitly
- Walks through one use case end to end with the model
Questions people ask about this interview question
- Which design type is this question?
- It is a low-level design question. You design an in-memory message queue and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Hard. It suits engineers preparing for senior interviews, where you are expected to drive the discussion and go deep on trade-offs.
- What should I cover first?
- Start with the use cases and the core entities, then the responsibilities of each one. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team