Message Queues & Pub/Sub

Message queues decouple producers from consumers in time. A producer publishes a message to a broker (RabbitMQ, Amazon SQS, Azure Service Bus, Google Pub/Sub). One or more consumers pull or receive messages and process them independently. If the consumer is down, messages accumulate in the queue until it recovers — the producer is not blocked.

Pub/Sub extends this to one-to-many: a single event is broadcast to every subscriber. An OrderPlaced event might trigger inventory reservation, payment capture, and a confirmation email — three consumers, one message. The key design decision is idempotency: consumers must handle duplicate messages safely, because brokers guarantee at-least-once delivery, not exactly-once.

Before

Synchronous chain — one failure blocks all

1await inventoryService.reserve(order);2await paymentService.charge(order);3await emailService.send(order);4// If payment fails, inventory is already reserved

After

Async queue — each step independent

1// Producer publishes one event2await broker.publish('order.placed', {3  orderId: order.id,4  items: order.items,5  total: order.total,6});7 8// Consumers react independently9// inventory-consumer  → reserves stock10// payment-consumer    → charges card11// email-consumer      → sends confirmation

Exercise

Publish one order.placed payload to a broker API you already use (or a local RabbitMQ/SQS dev setup). Write a consumer that acks only after a successful DB upsert keyed by orderId so retries are idempotent.