Async work with a queue
Async work with a queue
Gold
A queue lets the web tier hand slow side work, like notifying followers or sending email, to background workers and answer the user right away; the workers catch up at their own pace.
- Use when
- Slow or bursty side work — notifications, emails, webhooks · Smoothing spikes so workers run at a steady rate · Decoupling a producer from a slower consumer
- Avoid when
- The user needs the result in the same response · Work that must happen in strict order, unless the queue and workers are built for it
- Trade-offs
- The work finishes later, not sooner · Retries can deliver a message twice — handlers must cope · A queue that keeps growing means too few workers — watch its length
- Requires
- Split app and database tiers
3 objectives · 7 misconceptions
- predict Predict the response time when slow work moves off the request path onto a queue.
- explain Explain how a queue absorbs a burst, and what a growing queue says about worker capacity.
- choose Choose which work can run asynchronously — the user doesn't need its result in the response.
- Not true: Putting work on a queue makes the work itself faster.
- Not true: A queue can absorb any load forever.
- Not true: Any request can be made asynchronous.
- Not true: A new post has to be in every follower's feed before the author's post is confirmed.
- Not true: Each message is processed exactly once, automatically.
- Not true: Queue length doesn't matter as long as nothing errors.
- Not true: A request that hands its work to a queue still waits for that work to finish.