Protocol
Give queued work an expiry condition
A queue can preserve work long enough to make it useless.
When it fits
- A backlog can outlive the reason the work was requested.
When to avoid it
- Never expire legal, financial or safety obligations just because they are old; expiry must reflect actual business semantics.
Why it matters
For time-sensitive jobs, define when the result stops creating value. Store the request time or deadline and check it before expensive processing begins. Expired work can be dropped, rerouted or explicitly failed according to the business rule so fresh valuable work is not trapped behind obsolete requests.
Steps
- Old work has a defined business state instead of remaining indefinitely 'pending.'
An example
An AI-generated meeting brief requested for a call should not consume compute hours after the meeting has already ended.
Check your result
Old work has a defined business state instead of remaining indefinitely 'pending.'
Keep this limit in mind
- Never expire legal, financial or safety obligations just because they are old; expiry must reflect actual business semantics.
Connected ideas
Useful withMove poison work out of the main queue
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
AWS guidance recommends dropping or deprioritizing old queued messages when their business value has expired and the workflow allows it.
Expiry requires a real business rule; silently discarding durable obligations is unsafe.
REL05-BP04 Fail fast and limit queues · Drop old messages and prioritize useful work