System Design Interview Question: When Should You Use a Message Queue?

Short answer: use a message queue when work doesn't need to finish within the user's request, when producers and consumers should scale and fail independently, or when traffic bursts need buffering.

Classic uses

• Sending emails, generating PDFs, resizing images, calling slow third-party APIs.
• Smoothing spikes: accept 10,000 orders/second, process at the rate downstream systems can handle.
• Fan-out: one "order placed" event consumed by billing, shipping, analytics and email services.

[API] --"order.placed"--> [Queue/Topic] --> [Billing worker]
                                       --> [Email worker]
                                       --> [Analytics]

Queues vs logs

• Work queues (RabbitMQ, SQS): each message goes to one consumer and is deleted after acknowledgement. Great for task distribution.
• Logs/streams (Kafka, Kinesis, Redis Streams): messages are retained; many consumer groups read independently and can replay history. Great for event-driven architectures and high throughput.

Delivery guarantees

• At-most-once: may lose messages, never duplicates.
• At-least-once: the common default; never loses acknowledged work but can deliver duplicates.
• Exactly-once: limited to specific systems and setups; in practice achieved with at-least-once delivery plus idempotent consumers.

async function handlePayment(msg) {
  // Idempotent: processing the same message twice has no extra effect
  const inserted = await db.query(
    'INSERT INTO processed_messages (id) VALUES ($1) ON CONFLICT DO NOTHING RETURNING id', [msg.id]);
  if (inserted.rowCount === 0) return;   // already handled
  await chargeCustomer(msg.orderId);
}

Operational must-haves

• Retries with backoff, and a dead-letter queue for messages that keep failing.
• Monitor queue depth and message age; growing age means consumers can't keep up.
• Ordering: guaranteed only within a partition or message group; choose keys accordingly.
• The outbox pattern to publish events reliably along with a database write.