What is a message queue and when would you use asynchronous messaging?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
A message queue (RabbitMQ, Kafka, SQS) is a buffer that lets services communicate asynchronously: a producer publishes a message, a consumer processes it later. Use it to decouple services, smooth traffic spikes, handle failures gracefully, and order events. Trade-offs: you gain resilience and scalability at the cost of eventual consistency, added infrastructure, and the complexity of handling duplicates (idempotency) and ordering.
Detailed explanation
Message queues invert direct service-to-service calls. Instead of Service A calling Service B synchronously (and failing if B is down or slow), A publishes a message to a queue and continues; B consumes when ready. Core benefits: decoupling (producers and consumers evolve independently), resilience (if a consumer crashes, messages wait in the queue rather than being lost), load leveling (a burst of messages is absorbed and drained at the consumers pace), and ordering (queues preserve FIFO within a partition). Two models: point-to-point (RabbitMQ, SQS) — each message consumed by exactly one worker, good for task distribution; publish-subscribe (Kafka, SNS+SQS) — each message broadcast to multiple consumers, good for event streaming. Key concerns: at-least-once delivery means consumers must be idempotent; ordering is typically per-partition, not global; dead-letter queues capture messages that fail repeatedly; and back-pressure is needed when consumers fall behind. When to use: order processing, log aggregation, and any workflow where the caller should not block on slow downstream work. When NOT to use: when you need an immediate synchronous response or when the complexity outweighs the benefit.
Example
E-commerce order flow with a queue:
1. Order service writes 'order_placed' event to Kafka.
2. Three consumers process independently:
- Email service sends confirmation.
- Inventory service decrements stock.
- Analytics service updates dashboards.
If the email service is down, orders still succeed; email catches up when it recovers.Interview tip
Give the decoupling and resilience benefits first, then name the two models (point-to-point vs pub-sub) with an example each. Landing on idempotency as the key consumer concern shows you have operated these systems.
Common mistakes
- Not mentioning idempotency for at-least-once delivery.
- Treating queues as only for decoupling and missing load leveling.
- Forgetting that queues introduce eventual consistency.