Message queues
If service A calls service B synchronously, B's slowness or outage becomes A's problem, and bursts overwhelm B.
Open the interactive version → diagrams, practice & moreThe 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.
Interview 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.
Interviewer trap
Name the retry, duplicate, and DLQ behavior before drawing more boxes.