Most autoscaling rules for worker queues are wired to depth. When the backlog grows, add consumers. That rule is right exactly when the bottleneck is consumer capacity, and wrong the rest of the time.
Depth doesn't separate the two cases you actually care about. A queue holding forty thousand short-lived cache-refresh events can be completely healthy: it drains in seconds and nothing waiting on it has a deadline. A queue holding twelve payment commands that are an hour old is an incident, and it will never trip a depth alarm.
What separates them is the age of the oldest useful message, read against what that class of work is allowed to owe. Depth is a second-order fact about arrival rate. Age is a direct statement about whether you are meeting an obligation.
Then there is what happens when the depth rule fires against the wrong bottleneck. Elastic consumers scale in seconds; the thing behind them does not. The database has a connection ceiling, the third-party API has a quota, and the review queue has a person in it. Adding workers against a saturated dependency raises latency, which triggers timeouts, which produce retries, which is more load. Invocation count goes up and completed business effects go down. The dashboard shows a system working harder while less useful work leaves it.
So the number that should govern consumer concurrency is not the backlog. It is the slowest protected dependency's sustainable throughput, divided by the worst-case number of calls a single invocation makes. That second term is the one that gets skipped. A concurrency cap of 100 on a handler that fans out to five downstream calls is a cap of 500 on the thing you were trying to protect.
We wrote up the full control policy on our own site: how to set the dependency budget, where admission belongs relative to the queue, how event-source limits and function concurrency interact, and why a retry budget has to be bounded by a deadline instead of an attempt count.
Backpressure for Serverless Systems: Concurrency, Queues, and Overload Control
It includes the signal table we work from (what each metric reveals, which control it should move, and the misreading it invites) and a failure-mode table covering connection saturation, throttled third parties, poison messages and the recovery ramp, which is the phase where a released backlog turns into the second incident.
Written by the engineering team at Edilec.
