Message Queues

Overview

Message queues enable asynchronous communication between services. Instead of direct service-to-service calls, services publish messages to a queue, and consumers process them when ready.

This decouples services, improves reliability, and enables scaling of producers and consumers independently.

Key Concepts

Producer

Service that sends messages to the queue. Doesn't wait for processing.

Consumer

Service that reads and processes messages from the queue.

Queue

Stores messages until consumed. First-In-First-Out (FIFO) or priority-based.

Acknowledgment

Consumer tells queue "I processed this message successfully" so queue can delete it.

How It Works

Synchronous (direct call): Service A → (HTTP) → Service B

Service A waits for Service B
If B is down, request fails
A and B tightly coupled

Asynchronous (message queue): Service A → (publish) → Queue → (consume) → Service B

A doesn't wait
If B is down, message stays in queue
A and B decoupled

Example: Order Processing

User places order
Order Service publishes "OrderPlaced" event
Email Service consumes message, sends email
Inventory Service consumes message, updates stock
Analytics Service consumes message, updates metrics All consumers work independently!

Use Cases

Background job processing (email sending, report generation)

Event-driven architectures

Load leveling (absorb traffic spikes)

Decoupling microservices

Retry logic for failed operations

Fan-out patterns (one message, multiple consumers)

Best Practices

Make consumers idempotent (processing twice = same result)

Set appropriate message TTL (time to live)

Implement dead letter queues for failed messages

Monitor queue depth (growing queue = problem)

Use message acknowledgment properly

Implement retry logic with exponential backoff

Consider message ordering requirements

Log message processing for debugging

Interview Tips

What Interviewers Look For

•
Explain async messaging vs synchronous API calls
•
Discuss popular message queues: RabbitMQ, Apache Kafka, AWS SQS, Azure Service Bus
•
Mention idempotency: messages can be delivered more than once
•
Talk about at-least-once vs exactly-once delivery guarantees
•
Explain pub-sub pattern (multiple consumers) vs queue (single consumer)
•
Discuss use cases: email sending, order processing, event streaming
•
Mention dead letter queues for handling failures