The problem
If service A calls service B synchronously, B's slowness or outage becomes A's problem, and bursts overwhelm B.
The idea
Put a queue between them. A writes messages; B consumes at its own pace.
How it works
Producers enqueue work; the queue buffers it durably; consumers pull and process. This decouples availability (A works even if B is down) and smooths bursts (the queue absorbs spikes).
The tradeoff
You gain resilience and buffering but add eventual processing (work isn't done instantly) and must handle ordering/duplicates.
In the wild
Kafka, RabbitMQ, SQS. Order placed → queue → email, inventory, analytics consumers.
Deep dive
Flow
- Producer validates the request and writes a durable message.
- Queue acknowledges once the message is safely stored.
- Consumers pull at their own pace and commit progress.
- Retries use idempotency keys; poison messages move to a DLQ.
Watch for
- Queues move latency, they do not delete work.
- Consumer lag is a product signal, not just infra noise.
- Ordering is usually per key or partition, not global.
Common trap
Name the retry, duplicate, and DLQ behavior before drawing more boxes.
Common questions
What problem does Message queues solve?
If service A calls service B synchronously, B's slowness or outage becomes A's problem, and bursts overwhelm B.
How does Message queues work?
Producers enqueue work; the queue buffers it durably; consumers pull and process. This decouples availability (A works even if B is down) and smooths bursts (the queue absorbs spikes).
What are the tradeoffs of Message queues?
You gain resilience and buffering but add eventual processing (work isn't done instantly) and must handle ordering/duplicates.
Where is Message queues used in production?
Kafka, RabbitMQ, SQS. Order placed → queue → email, inventory, analytics consumers.