A message queue decouples a fast producer from a slow consumer: work is enqueued in milliseconds and processed asynchronously, so bursts queue up instead of timing out.
If you have thirty seconds to answer
A message queue lets one service hand work to another asynchronously: the producer enqueues in milliseconds and moves on, and the consumer drains at its own pace. You reach for one when a step is slow or bursty and the user does not need to wait for it — sending email, transcoding video, fanning out notifications. The cost you accept is delivery semantics: almost every queue is at-least-once, so consumers have to be idempotent.
Definition
A message queue is infrastructure that lets one service hand work to another asynchronously: producers enqueue messages in milliseconds and move on, while consumers drain the queue at their own pace. This decoupling is the main architectural benefit — a web tier can absorb a traffic burst by letting the queue grow, instead of timing out user requests while a slow downstream (video transcoding, email sending) catches up.
Queues also add fault isolation (a crashed consumer loses nothing; messages wait) and independent scaling (add consumers to drain faster). The key subtlety is delivery semantics: most queues guarantee at-least-once delivery, meaning a message can be delivered again after a consumer crashes mid-processing — so consumers must be idempotent. Queues do not make the work itself faster, and unbounded queue growth is a signal the consumer fleet is undersized, not a solution.
How it comes up in interviews
Reach for a queue whenever the design has a slow or bursty step that does not need a synchronous answer — notification fan-out, media processing, webhook delivery. Interviewers then probe semantics: what happens when a consumer dies mid-message (redelivery), why exactly-once is really at-least-once plus idempotent consumers, and what backpressure looks like.
What separates a strong answer
Common answer
Naming a product — "I'd put Kafka here" — and moving on to the next box in the diagram.
What lands
Saying what the queue buys you in this specific design (the web tier absorbs a burst instead of timing out), then volunteering the cost before the interviewer asks for it: at-least-once delivery, so the consumer needs a dedup key.
Message Queue interview questions
The forms this comes up in, and what a complete answer covers.
When would you add a message queue to this design?
When a step is slow, bursty, or allowed to fail independently, and the user does not need its result to complete their request. Notification fan-out, media processing and webhook delivery all qualify. The queue converts a synchronous dependency into a buffered one, so a spike grows the queue instead of timing out user requests. It is the wrong tool when the caller needs the answer to respond — a queue in front of a read path just adds latency.
A consumer crashes halfway through processing a message. What happens?
The message was never acknowledged, so after the visibility timeout expires the broker redelivers it to another consumer. That is the correct behaviour and it is also why at-least-once is the default guarantee: the work may run twice. The consumer therefore has to be idempotent — key the side effect on a message id, or make the operation naturally repeatable. A message that keeps failing should hit a redelivery limit and move to a dead-letter queue rather than blocking the partition forever.
How do you get exactly-once delivery?
You generally do not, and saying so is the strong answer. Exactly-once delivery across a network is not achievable in the general case; what systems actually provide is at-least-once delivery plus an idempotent consumer, which yields exactly-once *processing*. Some brokers offer transactional or exactly-once semantics within their own boundary — Kafka can do this producer-to-topic — but the moment a side effect leaves that boundary, such as charging a card, you are back to needing a dedup key or an idempotency table.
The queue is growing and never draining. What do you do?
First establish whether it is a spike or a trend. A growing backlog means arrival rate exceeds processing rate, so either add consumers, make processing cheaper, or shed load upstream. Unbounded growth is a signal the consumer fleet is undersized, not something the queue solves. Check for a poison message blocking an ordered partition, and check consumer lag per partition rather than in aggregate — one hot key can stall while everything else looks healthy.