AUTOMATION & WORKFLOWS
Laravel Queues at Scale: Lessons from Production
Laravel’s queue system works flawlessly in local development and in the first few months of production, which is exactly why the failure modes at scale catch teams off guard. At low volume, a stalled worker or a silently failing job is a minor annoyance. At millions of jobs a day, the same issue can back up an entire pipeline within the hour.
The first change we make on every high-volume system is separating queues by workload type — never running payment-related jobs on the same queue as bulk email sends. A slow or misbehaving job in one queue should never be able to starve a time-sensitive one.
The second is treating job idempotency as a requirement, not an optimization. Workers die mid-job during deploys, server restarts, and OOM kills; if a job isn’t safe to run twice, it will eventually run twice and cause a real incident.
Finally, monitor queue depth and processing latency as first-class metrics, not an afterthought. The single biggest reliability improvement we’ve shipped for clients wasn’t a code change at all — it was alerting on queue depth crossing a threshold, catching problems in minutes instead of discovering them the next morning through a support ticket.