A queue with no bound converts an overload into a latency problem that appears hours later and cannot be reasoned about.
unbounded accepts everything, delivers eventually.
"eventually" was six hours during the sale,
and the jobs were password resets.
bounded refuse above a depth, or above an age.
the caller finds out immediately, and can
shed load, degrade, or tell the user.
the number is a decision: how stale may this be before
doing it is worse than not doing it?
Framing the bound as a staleness budget rather than a queue length is what makes it agreeable to people who are not engineers: nobody will approve “refuse jobs above 10,000” and everybody understands “a password reset older than two minutes is useless”. Time-to-start is the metric that belongs on the dashboard, because queue depth without throughput says nothing about how long anything is waiting.