Why would you put a message queue between two services? What problems does it introduce?
Key points
- Decouples producer and consumer in time and availability, the producer does not need the consumer upIn plain words: The sender drops a message in a box and leaves, so the receiver does not need to be awake at that moment
- Buffers bursts so consumers can process at a steady rate and scale independentlyIn plain words: The box soaks up a sudden rush, and the receiver works through it at its own pace
- Enables fan-out, retries and dead-letter handling without changing the producerIn plain words: You can add more receivers, retries and a pile for messages that keep failing without touching the sender
- Introduces asynchrony, the caller no longer knows the outcome immediately and must design for eventual completionIn plain words: The sender no longer learns straight away how things went, so the design has to cope with finishing later
- Adds operational concerns, ordering, duplicates, backlog monitoring and the queue as a new critical dependencyIn plain words: It brings new chores such as order, repeats and watching the backlog, and it is one more thing that must not break
Model answer
A synchronous call couples two services tightly: the caller waits, and if the callee is slow or down the caller is too. A queue in between changes the contract: the producer writes a message and moves on; a consumer picks it up when it can.
What you gain
- Temporal decoupling. The consumer can be deploying, restarting or simply slower than the producer.
- Load levelling. A checkout spike produces 10,000 "send receipt" messages in a minute; the email workers drain them at 500 per minute without falling over.
- Independent scaling. Add consumers to drain faster; the producer never changes.
- Resilience patterns for free. Retries with backoff, dead-letter queues for poison messages, and fan-out to multiple consumers via topics.
What you pay
- Asynchrony leaks into the product. "Your export is being prepared" instead of "here is your export". You need status tracking, notifications or polling.
- Delivery semantics. Most queues are at-least-once; consumers must be idempotent. Ordering is usually per partition or per queue, not global.
- Observability. Queue depth and consumer lag become key health signals; a growing backlog is a silent outage.
- A new dependency. The broker itself must be highly available and sized for retention during a long consumer outage.
Interviewers want you to say why this particular edge should be async (the caller does not need the result, or the work is slow or bursty) and then immediately name the two consequences: idempotent consumers and a plan for telling the user when the work is done.
Likely follow-ups
- How do you let the user know when an async job has finished?
- What is a dead-letter queue and when does a message go there?