System Design · Architecture under constraints
What problems do message queues solve and what guarantees do they provide?
Short answer
Queues decouple producers from consumers, buffer bursts and enable retries. Most provide at-least-once delivery, so consumers must be idempotent; ordering and exactly-once require explicit design.
A message queue puts a durable buffer between a producer and a consumer. The producer can return quickly without waiting for downstream work, the consumer can process at its own rate, and a failure can be retried instead of losing the request. This improves resilience and absorbs traffic spikes.
What a queue gives you
- Temporal decoupling: the producer does not need the consumer to be up
- Load leveling: a burst is buffered and drained at a sustainable rate
- Retries and dead-letter queues for messages that repeatedly fail
- Competing consumers: multiple workers share the backlog
- Backpressure: queue depth becomes a visible signal of overload
Delivery semantics
- At-most-once: a message may be lost but is not delivered twice
- At-least-once: a message is not lost but may be redelivered, so consumers must deduplicate
- Exactly-once delivery is generally not a property of the queue alone; it requires transactions or idempotent effects
- Visibility timeout hides an in-flight message so another worker does not take it immediately
- Ordering is usually guaranteed only within a partition or queue, not globally
A consumer should acknowledge only after the effect is durable. If it acknowledges before committing, a crash loses work. If it commits and then crashes before acknowledging, the message is redelivered, which is why idempotency is mandatory. Poison messages need a retry limit and a dead-letter queue with an alert, or they will block a partition indefinitely.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Why is exactly-once delivery hard to guarantee?
- 2What is a visibility timeout and what happens if it expires?
- 3How do you handle a poison message?
- 4How does queue depth help with autoscaling?
Say it in the interview
A queue decouples producers from consumers and buffers bursts so downstream work can proceed at its own pace. Most queues give at-least-once delivery, so I design consumers to be idempotent and acknowledge only after the effect is committed. I use retry limits and a dead-letter queue for poison messages, and I rely on ordering only within a partition. The queue moves work; it is not the source of truth.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.