Queue Worker Prioritization: Architecting Laravel Job Hierarchy

Previously in this course, we explored Eloquent Caching Strategies to reduce database load. While caching improves read performance, background processing is the backbone of any high-traffic SaaS. Today, we advance our architecture by implementing Queue Worker Prioritization to ensure your most important domain events aren't stuck behind a massive batch of low-priority emails or report exports.

The Problem: When Everything is Urgent, Nothing Is

By default, Laravel processes jobs in a FIFO (First-In, First-Out) manner on a single default queue. In a production SaaS, this is a recipe for disaster. If a user triggers a batch job that generates 5,000 PDF reports, your critical "Send Password Reset Email" or "Process Payment Callback" jobs might sit in the queue for minutes.

To achieve a production-grade architecture, you must move from a single-queue mindset to a tiered queue hierarchy.

Defining Named Queues

Instead of dispatching every job to the default pipe, categorize your jobs based on their business impact. We typically categorize them into three tiers:

1. High: Critical path tasks (e.g., payment processing, security alerts, user authentication flows).
2. Default: Standard application logic (e.g., sending notifications, clearing caches).
3. Low: Heavy, non-time-sensitive tasks (e.g., analytics processing, report generation, daily cleanup).

You assign a queue to a job using the onQueue() method during dispatch or by defining it in the job class:

PHP
#6A9955">// Dispatching with explicit priority
ProcessPayment::dispatch($order)->onQueue('high');

#6A9955">// Or defining it within the Job class
class GenerateMonthlyReport implements ShouldQueue
{
    public $queue = 'low';
}

Configuring Worker Priority Order

Defining queues is only half the battle. You must instruct your queue:work processes to consume these queues in a specific order. When you start a worker, the order of the queue names matters significantly.

Run the following command on your production server:

Bash
php artisan queue:work --queue=high,default,low

In this configuration, the worker will always check the high queue first. It will only move to the default queue if high is empty. If a new job arrives in high while the worker is busy with a default job, the worker will finish the current job and immediately jump back to the high queue.

Queue Hierarchy Strategy

Worked Example: Scaling the SaaS Platform

In our running project, we need to ensure that when a user upgrades their plan, the billing sync is instant, while the "Welcome Email" series can wait a few seconds.

1. Define the Job

PHP
namespace App\Jobs\Billing;

class SyncSubscriptionStatus implements ShouldQueue
{
    public $queue = 'high'; #6A9955">// Always process billing syncs first
    
    public function handle() { #6A9955">/* ... */ }
}

2. Deploy Specialized Workers On a high-traffic system, you shouldn't just rely on one worker command. Use a process manager like Supervisor to run multiple workers with different configurations:

INI
; /etc/supervisor/conf.d/laravel-worker.conf
[program:laravel-worker-high]
command=php /var/www/html/artisan queue:work --queue=high --processes=2

[program:laravel-worker-default]
command=php /var/www/html/artisan queue:work --queue=default,low --processes=4

By dedicating specific processes to the high queue, you guarantee that even if the low queue is flooded with millions of rows of analytics, your billing syncs remain isolated and performant.

Hands-on Exercise

1. Identify three jobs in your project that are currently in the default queue.
2. Refactor them into high, default, and low tiers.
3. Update your local docker-compose.yml or supervisor config to start a worker that prioritizes the high queue.
4. Verify the order by dispatching a low priority job, then a high priority job, and observing the logs to confirm the high one executes first.

Common Pitfalls

• Queue Starvation: If you have a poorly optimized high queue that is constantly full, your low queue jobs will never run. Monitor your queue depths using tools like Advanced Queue Monitoring: Mastering Laravel Horizon.
• Forgetting to update Supervisor: A common mistake is updating the code to use named queues but failing to update the production php artisan queue:work command. The worker will continue to listen only to the default queue, effectively ignoring your new high and low queues.
• Context Propagation: When moving jobs across queues, ensure you aren't breaking trace context. If you're using observability tools, check Laravel OpenTelemetry Distributed Tracing: Async Queue Context Propagation to ensure your logs remain correlated across the different queues.

Recap

Queue prioritization is about resource isolation. By partitioning your workload into named queues and configuring worker priority, you prevent background noise from degrading the user experience of your critical domain services.

Up next, we will handle Unique Job Patterns to prevent race conditions and duplicate processing for those critical domain events.