Principle
Use queueing only when delayed work remains valuable
A queue stores pressure; it does not create capacity.
When it fits
- Every overload problem is being solved by adding a larger queue.
When to avoid it
- Some durable workloads still have compliance or ordering requirements that prevent dropping or reordering old work.
Why it matters
Before buffering work, ask whether asynchronous delay is acceptable and whether the result retains value after waiting. If the request needs a timely response, prefer bounded queues, rejection or degradation. If the work is durable, queue it with expiry, backlog monitoring and failure isolation.
An example
Queue offline document indexing; do not put interactive authentication requests behind an hour-long backlog.
Check your result
Every queue has a reason why waiting preserves value rather than merely postponing overload symptoms.
Keep this limit in mind
- Some durable workloads still have compliance or ordering requirements that prevent dropping or reordering old work.
Connected ideas
Useful withGive queued work an expiry condition
Evidence and sources
AWS recommends monitoring message age and avoiding long queue backlogs that process work after it is no longer useful.
Some workloads require strict processing of old items for legal or consistency reasons.
REL05-BP04 Fail fast and limit queues · Queue backlog anti-patterns and message age
Google SRE recommends small queues or early rejection under steady overload because long queues add latency, memory use and work that may already have missed its deadline.
Bursty asynchronous workloads can legitimately benefit from larger queues when backlog remains useful.
Addressing Cascading Failures · Queue management and latency/deadlines