Message Queues & Async Processing
Decoupling a slow or unreliable step from the request path by handing it to a queue and processing it separately.
What it is
Instead of doing all work synchronously within a single request (client waits for every step to finish), a message queue lets a service publish a message describing work to be done, and a separate consumer processes it independently — the original request can return immediately.
Why decouple
- Latency — a user-facing request returns fast even if downstream work (sending an email, resizing an image) takes seconds.
- Reliability — if the consumer is temporarily down, messages wait in the queue instead of being lost; many queues support retries and dead-letter queues for messages that repeatedly fail.
- Load leveling — a burst of requests becomes a burst of queued messages, processed at a steady rate the consumer can handle, instead of overwhelming it directly.
Delivery guarantees
Queues typically offer at-least-once delivery (a message might be processed twice if a consumer crashes after processing but before acknowledging) — which means consumers should be idempotent (processing the same message twice has the same effect as once), rather than relying on exactly-once delivery, which is much harder to guarantee.
Prerequisite
Assumes the stateless/horizontal-scaling vocabulary — a queue is what lets producers and consumers scale independently of each other.