Stop defending numprocs=10: derive queue workers from a latency promise

A developer spent a week on a demo app replacing the hardcoded worker count in a Laravel supervisor config with a declared pickup deadline, using cboxdk/laravel-queue-autoscale plus cboxdk/laravel-queue-metrics, and published the measurements ^[1]. The reason to read it is not the package: it is that `numprocs=10` is a number nobody at your company can defend, picked years ago and left there while the load changed around it ^[2].

The failure is symmetric. Set it too low and jobs wait minutes during a campaign blast; set it too high and you pay for RAM all night for workers doing nothing ^[3]. The alternative is to declare one thing, a service level such as "a job on this queue must be picked up within 10 seconds", and let a manager process solve every five seconds for workers = (pending jobs / SLA seconds) / jobs per second per worker ^[5]. With 3,000 pending jobs and a 10-second promise you need 300 jobs per second; a job that takes about 100ms gives one worker about 10 per second, so the formula asks for 30 workers ^[6]. This is Little's Law, the 1961 result behind checkout lines and CPU schedulers, and the point is that the only human input is a business question rather than a process count ^[7]. If you have ever sized a PHP-FPM pool as RAM divided by average process size, it is the same move: measure one unit, derive the count ^[8].

What the run actually did is the interesting part. The configuration capped the queue at 16 workers, and the cap won over the formula's 30; the package also caps by measured host CPU and RAM ^[10]. Sixteen workers at ten jobs a second is 160 jobs a second, so a 3,000-job backlog needs roughly 18.75 seconds to clear, which means at the cap the declared 10-second promise is arithmetically unreachable and the cap, not the SLA, is the operating policy ^[12]. That is a useful thing to be able to say out loud. All 3,000 jobs completed with none lost, and on SIGTERM each worker finished its in-flight job before exiting ^[11].

The guardrail worth stealing is the failure fuse. With 2,000 jobs that all throw, the manager logged a 100% failure rate over 28 jobs and held at the minimum, noting that the backlog of 1,999 required 999.5 workers to prevent an SLA breach ^[13]. It allowed one, roughly a thousandfold gap between what the backlog demanded and what was permitted ^[15], keeping that worker as a probe until the failure window aged out at 0% over 387 jobs and normal scaling resumed without a restart ^[14].

Cost behaviour is deliberately asymmetric: scale-down removes one worker per cycle with an anti-flapping cooldown ^[16], so returning from 16 workers to 1 takes at least fifteen five-second cycles, about 75 seconds, before any cooldown ^[17]. You pay a short idle tail on purpose instead of yo-yoing.

Two operational notes from the same writeup: the manager needs ext-pcntl, and v4 also ext-posix, and every queue entry needs an explicit `connection` or it silently hunts for a connection named `default` and every evaluation fails into the log ^[18]. Delivery semantics do not change. Laravel's Redis reservation pops and reserves in one single-threaded Lua script, so two workers cannot claim the same job ^[19], but the guarantee is still at-least-once: retry_after defaults to 90 seconds, a dead worker's job returns to pending, and idempotency, ShouldBeUnique and WithoutOverlapping remain your problem ^[20].

Watch your own per-worker rate before trusting any of this arithmetic; ten jobs a second is a 100ms demo job, not a PDF renderer ^[6]. Then check whether the SLA you declare implies a worker count you are willing to fund, and whether a 28-job failure window matches how your payment provider actually dies ^[13].