Queues & Async Processing
Moving work off the request path is the most common fix in system design. It also hands you duplicate deliveries, reordering, and a backlog you have to reason about.
Prerequisites: Synchronous request/response, and one thing you wish were not in the request path.
After this: Reason about delivery guarantees, ordering, and poison messages before choosing a broker.
Suggested first pass: Read sections 1–5, answer each section in your own words, then use the remaining failure modes and exercises as the advanced pass.
A user uploads a video. You could transcode inside the request and let them watch a spinner for four minutes. Instead you save the file, put a message on a queue, and answer immediately. A worker picks it up later.
Three distinct benefits, and it is worth saying which one you are after:
- Latency. The user stops waiting for work they do not need to see finish.
- Smoothing. Traffic arrives in bursts, workers consume steadily. A 10× spike becomes a longer backlog rather than an outage.
- Decoupling. The producer does not need the consumer alive. Deploy, restart, or scale the worker without the API noticing.
The work is now eventually done, not done. The user gets "we're processing it", which means the product needs a state to show and a way to report failure later. Every async design owes an answer to "how does the user find out it failed?", and forgetting it is the most common gap in an otherwise good answer.