Member-only story
Laravel Queues at Scale: The Lessons That Only Show Up in Production
Dispatching a job is one line of code. Running millions of them without losing sleep is an architecture decision.
Let me ask you something: do you know what happens to a job in your Laravel app when it fails for the third time at 3 a.m.?
Not what the documentation says happens. What actually happens in your system. Who finds out, how long it takes, and whether the customer notices before you do.
Queues are one of the best things Laravel gives you. ShouldQueue, a Redis connection and Horizon, and suddenly the slow parts of your app move out of the request. Emails, PDFs, webhooks, imports, syncs with third-party APIs. The app feels fast again and everyone is happy.
Then the volume grows. A few hundred jobs a day become hundreds of thousands, and the queue stops being a background detail. It becomes the part of your system that does most of the real work. In the teams I’ve led, that’s the moment when the bugs change shape: they stop being exceptions in a stack trace and start being jobs that ran twice, jobs that never ran, and jobs that ran in the wrong order.
The lesson I keep relearning is simple. Queues don’t fail because Laravel is weak. They fail…
